Just to confirm if multithreading is supported in iPad and iPhone. I need to write an application that calls a web service on a background thread while user can still interact with the UI.
Yes, it has threads.
Also, you don't need to spawn your own threads for most tasks. A lot of the Apple Frameworks (Cocoa Touch Foundation frameworks) have built-in code that will do this for you.
Also, if you're consuming data from a Web API (HTTP Request), I highly recommend you take a look at ASIHTTPRequest, which is built on top of NSOperation (an operation class that easily handles background processing).
Finally, if you need help on program design/flow using the Model-View-Controller pattern, I've written a blog entry describing how to consume Web API data and present it to the end-user in a table format.
iOS has always supported multi-threading, just as Mac OS X did before it. Here's Apple's excellent overview documentation on the subject:
Concurrency Programming Guide
Related
We're planning on implementing a server-side notification mechanism that pushes out to iOS and Android via ANH. We will have no code footprint on our mobile clients, short of a call to our server API for "registration". In this way our approach is looking similar to this MSDN discussion.
I also see the alternate, more bare-bones, approach noted on MSDN.
Is it fair to conclude that the two approaches will have similar performance on the 'send' side?
It appears the main difference is this:
The former approach has already done the work of integrating with the Task and Async mechanism, presenting a callable C# mechanism that has taken on more of the RESTful API layer,
The DirectBatch/Send API is just that -- the raw RESTful API for you to use as you see fit.
For operations that are available as both REST API and SDK, you shouldn't see any significant difference in performance on the client side because the SDK is just a wrapper around the REST APIs. There are SDKs for both iOS and Android and it's recommended to use those so that you don't have to re-write the wrapper.
Direct Send is only available in .NET SDK at the moment and for other platforms as REST API, so you'd have to implement your own wrapper in case you're using something other than .NET for the operation. You can use the sample to help you in the process.
In terms of performance it depends on what you mean by that.
Direct send will most likely be delivered to customers a bit faster because ANH service doesn't have to do any registrations in the process, it just delivers notifications with your parameters. But it has it's limitations in terms of number of handles you can provide and also you need to manage handles yourself.
If you only mean performance on the client side, then there should be no difference as all calls are asynchronous. And if you take advantage of tags, then you can do really tricky sends in one server call and let ANH figure out the details behind it.
But without knowing your scenario and requirements there's no way to give a proper recommendation.
I want to be clear: I am asking about the case where I am not using any concurrency in my own implementation. I just want to know if the framework within which my backend will be invoked (ie google app engine) itself imposes thread-safety requirements on the code running on it.
Thank you!
P.S. as a related but separate question, is there any guidance on how to do multithreading in our own backend code (which then obviously needs to be appropriately thread-safe). Specifically, can we use java's standard executor services / thread pools, or there is some google-approved API? Thanks.
So google app engine or any other platform won't ensure thread safety for you because all the critical sections which your concurrency control techniques are trying to make thread safe are defined by the developer (you) and there is no way for the OS to know when reads and writes should occur. For the JVM, the two main concurrency libraries which are heavily used are the Guava libraries (made by google! ;-) ) and the Akka framework.
Both are great libraries, I've used both and have had a pleasure from their learning curves. I would also recommend looking into the Play Framework, they support the akka framework, and building reactive web apps is their main focus. If you're interested in learning some cool aspects of production frameworks, I would highly recommend learning and implementing Dropwizard (Google app engine doesn't support it, but the take aways you get from it definitely outweigh that con).
Please let me know if you have any questions!
Multi threading in windows phone C# ?
How to do multithreading when i call a wcf service . One thread should call service and one thread should show processing.
I've never programmed for windows phone but I have a fair bit of experience with c# and a quick google search shows windows phone has support for BackgroundWorkers. I would suggest using that for your time consuming task, you can even get a progress update. Check this out for an example:
http://msdn.microsoft.com/en-us/library/windowsphone/develop/cc221403(v=vs.105).aspx
It's what I use when calling a WCF service from a WPF app
WP7 has a BackgroundWorker class that can help you.
It has the WorkerReportsProgress property and ProgressChanged event that can inform you about its progress.
BackgroundWorker seems like a good choice given your description of the problem. It is pretty easy to work with. But it is also worth mentioning that there are other methods to do multithreading on Windows Phone 7 such as a ThreadPool.
I can recommend checking out this question (and answers) which describe the possible options:
Background Threads in Windows Phone
I have a telephony scenario in which the following happens:
Customer calls a Voice Gateway
TCL script runs and a code is taken from customer
Authentication is done through a RADIUS server
Customer will hear correct voice menu
The problem is that RADIUS server must connect to a SQL Database and check the credentials. I have currently designed the solution using cisco secure ACS and through managed stored procedures on MS SQL server.
My question is: Is the VoiceXML a better tool to do this job and because some extenstions and wrappers of VoiceXML exists in .net, does it fit in this simple scenario??
Sincerely speaking, I am a little confisued with the technology and looking for a good tutorial on its features as well.
Thanks
In a strict sense, only step 4 is implemented by VoiceXML. Other aspects are handled by the platform or external code. VoiceXML is the standards mechanism for implementing step 4, but if all you are going to do is limited audio output and simple input, it may be overkill depending on the solutions available to you.
The following is just an example of a way to solve your problem and is fairly fictitious given I don't know anything about your environment nor constraints.
Given most VoiceXML platforms, upon receiving of a call your VoiceXML application will be executed. If this is a servlet/ASP based solution, you can perform steps 2 & 3 then generate/return the VoiceXML to play the menu, gather the input and move to the next step. If this is a static VoiceXML 2.1 solution, you can use a Data element call to make an HTTP request to a system that can perform these actions. The system will need to return XML that the Javascript/ECMAScript in VoiceXML application can parse and provide the correct audio output and input processing.
Since you are asking about VoiceXML, I'm assuming your challenge is the telephony aspect of the problem. Unless you have a system already available, choosing and activating a premise or hosted solution is far more complicated than the call flow code involved. Depending on your requirements, there are solutions as low as a single line, analog modem that supports audio output and DTMF input to massively scaled on premise and hosted solutions to handle 10,000s of concurrent calls that implement VoiceXML as well as a wide range of other call flow technologies.
VoiceXML would work fine in this scenario. There is a an open source project called VoiceModel that uses ASP.NET MVC to generate the VoiceXML and therefore integrates nicely with the .NET stack. There are a lot of examples in the project with discussions on how to use the examples in this blog. The examples use Voxeo Prophecy as the VoiceXML platform which has a SIP interface that will connect with a Voice Gateway. You can download two ports for free to try it out.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I am looking for a Threading framework to use in my Delphi application.
Currently I am evaluating ‘OmniThreadLibrary’ - so far it looks good and does everything I need.
Is there any other ‘Threading framework’ for Delphi ?
(I am using D2006 & D2009)
As per Vegar Suggestion
Based on my few hours of evaluating OmniThreadLibrary
Here are some of the things I like about it
1) It is simple to use
2) It hides most of the details about multi threading
3) With a few lines of code you can set up multiple threads
4) It is easy to do inter process messages
5) It is still been actively developed
Not a framework as such, but there's AsyncCalls. Its scope is different from OmniThreadLibrary, but it supports older versions of Delphi as well.
Internet Direct (Indy) contains IdThread and thread safe data types in IdThreadSafe.pas:
* TIdThreadSafeInteger
* TIdThreadSafeBoolean
* TIdThreadSafeString
* TIdThreadSafeStringList
... and some more
The Jedi Code Library (JCL) also includes synchronization classes and functions (around ten classes)
I have been developing my own extensive threading framework, which is also integrated with a similarly architected communications framework, over the last 10 years. At this stage it can be used with Delphi 2005-2007, but will soon be available for Delphi 2009-2010. This application development framework can be used to build massively distributed systems as it is designed to enable any threads to run in any process and uses a simple thread-communications protocol that is the same whether the threads are in the same process, or in different processes on different machines.
As an additional feature I have this framework now running in C#/Visual Studio so a distributed system built using this framework can have a mix of Win32 and .NET applications, all using the same design methodology. The framework can be downloaded from http://www.adug.org.au/downloads/CSIFramework.html
The libraries that are used by my framework are not as extensive as it must have appeared from the site (I have just reworded that page, but it may take a day or so to be updated). Furthermore, all required files (apart from the database abstraction layer) are included with the framework, so no third-party libraries need to be installed to use the framework.
Beyond Delphi, the libraries used are:
Indy (included with Delphi, although I use the latest pre-unicode version)
JEDI JCL
Turbopower Abbrevia
an XML tidy library (optional)
a database abstraction library (optional)
I have modified some peripheral Delphi units 1) to fix a memory leak in the open XML implementation in Delphi 2006 (subsequently fixed in later Delphi versions), 2) to integrate the service application with my logging framework, and 3) to integrate the stand-alone SOAP server with Indy 10 (not Indy 9 as included with Delphi 2006).
In reality, my framework is much, much more than just a threading framework, although the threading framework is part of it. The threading framework is built by implementing all threads as threaded queues. The "messages" passed between the threaded queues are actually data packaged in a generic typed object, which allows me to pass absolutely any data structured in any way between threads. I can pass messages between threads either asynchronously, by adding a message, or synchronously, by adding a message and receiving a message in response. The threads themselves subscribe to other threads to receive messages, so there is no coupling between the threads at design time.
This framework has been extended to include communications servers and clients, and the main GUI thread, to have exactly the same messaging interface as the threaded queues, so sending a message to a remote process, or passing it onto the GUI, uses the same syntax as that used between threads. The framework has been designed in a way that there is no requirement to know anything at all about multi-threaded development to build a distributed system deployed across multiple processes and multiple threads.
There is a lot more to the framework than this and I have put in more than 2 years worth of effort to develop this over the last 10 years. It has been successfully deployed in a multi-tier alarm monitoring system (utilising over 20 different classes of thread across three applications), and I am currently building a distributed system in Visual Studio 2008 using this framework.
In short, if all you want is a simple threading framework, then this is probably overkill. However, if you want to develop a complex multi-threaded system which might span multiple applications then the learning curve may be worth it.
PS Another few points:
Thread startup and shutdown is all handled by the framework (no need to write any code to do this)
The threads that comprise the application (number and configuration) are all defined in an an XML configuration file, not in the code itself (no need to write any code to include them in the application)
If you use the database abstraction component then multi-threaded database access is automatically available (no extra code required)
I am currently working on adding thread pooling, which will allow any threaded queue to have a specified number of instantiated threads (again, no need to write any code to do this)
There is a simple developer's guide that you can download from the web page which is also included in the framework download that gives an overview of the framework from a developer's perspective
The framework itself is under very active development, and with the next release of Delphi I hope to have a version running on Win32 (under Delphi), a .NET version (C#/Visual Studio), and a Linux version (using the new Deplhi cross-platform compiler)