I am building an IOS application using Flex 4.6 and AIR 3.3. I do have some Objective-C Libs that we will be using for processing audio, images, and video to create a new "video" file.
Being that we are doing all this processing on the device through a native extensions I am wondering if the user is going to see the app lock up till the processing is complete. In other words am I going to need to show them a progress bar and not allow them to do anything else in the app till this is complete OR does native extension code run in a separate thread ?
A secondary question would be ... If Native Code does not run in a separate thread is it possible to use the new Actionscript Workers to offload the processing to a separate thread ?
Your ANE can invoke a new thread, so your app shouldn't lock up.
This is a very good reference for developing native extensions: http://help.adobe.com/en_US/air/extensions/air_extensions.pdf
To quote the relevant part:
"The native C code can dispatch asynchronous events back to the ActionScript side of your extension. For example, an extension method can start another thread to perform some task. When the task in the other thread completes, that thread calls FREDispatchStatusEventAsync() to inform the ActionScript side of the extension. The target of the event is an ActionScript ExtensionContext instance."
Regarding the worker threads, yes, that's exactly what worker threads are for and from what I've read from the AS3 implementation, it'll work just like that. However, my best bet is that using an ANE will be faster for such tasks than using AS3. If you have the libs ready to roll, I'd just use an ANE and maybe try the worker threads once released for fun, might be easier to maintain if you're mostly developing in AS3.
Related
I'm working on a game that heavily depends on audio API of Corona SDK. The game neads to load a couple of sounds (wavs) and a relatively big background music (+15mb) I don't want to steam the files couse of a statement that I read in corona guides.
Note that streamed files may have a slightly higher latency cost and CPU cost than files loaded with audio.loadSound().
I'm using composer API and I'm planning to develop a loading screen based on event cycle.
My question is can I depend on audio API that if I put all of my loadSounds to the create event handler and they all going to load synchronously and then the show event will be dispatched after all of audio files loaded?..
...Or should I use a diffrent approach for my loading screen?
Yes I believe they are loaded synchronously.
On my apps with a larger background music file the load screen will take longer on slower devices. So it blocks until it is loaded.
I would imagine this is the case since there is no mechanism to 'query' or a callback for when audio is loaded if it was asynchronous.
But don't take my word for it, test it.
PS: Your solution does seem to be solid though, that's about what I do.
I have an Android application using MvvmCross. The App launches via an MvxSplashScreenActivity as the main launcher and I provided a setup class deriving from MvxAndroidSetup.
It seems however that my MvxAndroidSetup.CreateApp() override is called on a ThreadPool thread (see https://github.com/slodge/MvvmCross/blob/vnext/Cirrious/Cirrious.MvvmCross.Droid/Views/MvxBaseSplashScreenActivity.cs#L79).
What is the best way to ensure certain parts of my App Initialization are performed on the MainThread?
Most of the modern platforms - WindowsStore, WindowsPhone and iOS - allow you to bundle a static Default.jpg (or similar) to entertain your users while your app starts.
Android doesn't do this - it simply launches your app using the Activity marked as the MainLauncher.
If your app needs to do some initialization work (as most MvvmCross apps do) then this leaves you with a choice - do you do that work on the UI thread (which then results in an unresponsive UI) or do you display a placeholder SplashScreen and then do the initialization work on the background thread.
This is what MvvmCross tries to allow you to do
it provides you with a splashscreen class
it overrides the OnCreate of the splashscreen to do the minimal work it can on the UI thread during the splashscreen OnCreate (during this time the UI is black which is horrible)
then it does the bulk of init on a threadpool thread - as #CheeseBaron has pointed out on MvxBaseSplashScreenActivity.cs#L79
The bulk of initialisation - loading types, starting services, recovering settings, loading language files, etc - shouldn't need to be done on the UI thread.
If there is some part of initialization that you need to do on the UI thread, then it's up to your app to work out how and when to marshal that work back to the UI - e.g.
by using MvxMainThreadDispatcher.cs
by deferring that task until a later time (e.g. using Lazy IoC which will be triggered by viewmodel creation)
by overriding the SplashScreen's OnInitialisationComplete method
However, obviously at no point should you try to marshal any long-lasting work onto the UI thread... the UI thread is for the UI, not for heavy calculation or for any blocking work.
You should aim to keep the UI responsive, even during startup.
Detailed note:
The above description covers the 'normal launch' of an app from e.g. the android Home page.
However, if you dive deeper, then this is not the only way an app can be started - it can also be started from push notifications, from recovering from being killed ("tombstoned" in WP speak) or from things like broadcast receivers.
In those situations, the MvvmCross app initialisation may occur in other ways than described above:
in the case of an MvxActivity being directly launched (e.g from push or after recovering from tombstoning), then the whole of Setup is currently run on the UI thread during the OnCreate of that activity - this isn't ideal and is something I would hope the framework can improve on in the future.
in the case of a background service starting, it's up to the app engineer to work out what to setup when - e.g. see Using MvvmCross from content providers and activities
One opportunity for an alternative startup route is to subclass the Android Application object - see http://developer.android.com/reference/android/app/Application.html
I have a game that I'm getting ready to submit. I've tested it a lot and it seems to be solid -- no crashes and no unexpected behavior. I am not forcing anything to run on the main thread (except for one place where I followed a sample in a book) and now I'm concerned that under some circumstance, on somebody else's device, the game will not work right or crash because I'm not doing something on the main thread that should be on the main thread. But I don't understand what needs to be run on the main thread. I googled for a checklist or summary of what methods need run on the main thread and didn't find anything useful. Is this something I need to worry about? The app is for iOS 5.1 and up and it uses in-app purchases and Game Center. I use the cocos2d framework and also a lot of UIKit stuff.
most methods running on the main thread are fine,
especially the UI,
you want to use the back thread for processes that can take long, like http requests, database or data sorting, or any other process that can pause the user experience while is processing.
if you load lots of objects you can produce a memory warning that can result in a crash,
so you can release non needed objects when you get a memory release.
good luck
I have a question that I can't really answer, so I wonder if someone may shed some light here.
Basically I am interested in knowing what is going on in iOS before and while I run an app...but from the OS perspective.
I've seen a lot of posts regarding what happens when the user tap on an app in the main screen, but I am interested in knowing basically what happens behind the scenes, before that the app takes control and main runs the singleton for UIApplication. And also once that the app is running, is the whole OS blocked in the main run loop of the app or something else is going on?
In particular, I would like to understand who creates the process where UIApplication will run (so the whole app will run inside that process, I assume).
Also would like to know what is the OS doing when for example, I open a connection in an app...since I see that a new thread is created (looking at a crash report I see a bunch of threads running, not just the main one), but I don't get where and who creates them (UIApplication itself?, where they running already before launching the app?).
Hope that the question is clear; I've search all over to find info but all that I get is that when you tap an app, main() runs and calls UIApplication,which takes control, deal with the delegate and views and so on...but what is going in the OS is a mystery.
Is there any resource related to the iOS part? Thanks!
The operating system of the iPhone works really similar to any other modern operating system. There is a kernel which provides low level functions, an API that provides high level functions (either to applications either to the OS itself) and so on.
There are a lot of processes always alive in the OS itself, just think about the fact that the device is able to receive notifications, receive calls, manage connections and whatever it needs to run.
When you launch an application the only thing that changes is that a process is launched and the control of it is given to the application.
And also once that the app is running, is the whole OS blocked in the main run loop of the app or something else is going on?
The whole OS is not blocked, the process launched is just scheduled together with many other processes that constantly run. This is achieved by multi-tasking.
In particular, I would like to understand who creates the process where UIApplication will run (so the whole app will run inside that process, I assume).
The process is created by the OS itself, which istantiates a new process structure to manage the just launched application and schedule it (with a high priority since it will run in foreground).
(UIApplication itself?, where they running already before launching the app?).
Threads are similar to processes in the sense that they have their code and they actually do something but a thread is lightweight because many thread can be managed by just one process. This mean that your application (or an API call) can create a thread which will run together with the main thread of your application and manage their operations but all these thread will share the same CPU allocation time and the same memory space and whatever. Actually Cocoa hides many of the details from a developer point of view, so that you don't care exactly about which threads are automatically started by the application because you don't need to: they are used to dispatch messages between objects, to manage asyncronous events and whatever.
But this is just the tip of the iceberg, before understanding how iOS works you should learn how a lower level infrastructure works, eg BSD Unix which is actually one of the ancestors of Darwin, which is the kernel on which iOS is operating. After understanding how it works you will undersand also how the infrastructure over it works (which is iOS + its API).
I have an iPhone app which pretty much is a mobile app for a website. Pretty much everything it does is call API methods from our server. The app retrieves the user's information, and keeps updating the server using the API.
My colleague and I had a discussion whether to introduce GCD to the downloading aspect on the app. My colleague argues that since the UI needs to wait for the download to complete before it can display the pictures, text or whatever, there is absolutely no need for GCD. My argument is that we should keep the main thread busy with UI rendering (even if there is no data), and introduce GCD to the app to create other threads for download.
Which argument is right here? In my case, if the UI renders with no data, will there be some sort of lag? Which will yield a cleaner, sleeker and faster app?
One argument would be : what will happen when the download fails and times out because there is a problem at the server end ?
Without GCD the app will remain blocked and will crash after a time
out since the UI can not be blocked for longer than 20 seconds.
With GCD the application remains functional but there will be no data
being downloaded and the application will not crash.
Other aspects to take into account are :
the thread safety of the objects that you are using
how you handle downloads that are no longer necessary because the user navigates away from the page
I don't think doing time consuming operations in the main thread is a good idea.
Even if user have to wait for the data te be downloaded before he can do anything meaningful, still he will not hope UI is blocked.
Let's assume you have a navigator view, and after user tap some button, you push a new view to it and start download something. If user suddenly decides he don't want to wait anymore, he tap the "back" button. If your downloading operation blocks UI, user will have to wait it to end, it's really bad.
A more appropriate question would perhaps be if you should download asynchronously or on the main thread for your app, since there are several different methods to download asynchronously on iOS (e.g. using NSThread, NSOperation or indeed GCD). An easy approach to achieve your goals could be to use the AFNetworking library. It makes multithreaded networking / internet code very easy to implement and understand.
Personally I'm very fond of GCD and recommend you learn it someday soon, though in itself it is not as suitable for asynchronous downloading compared to a library like AFNetworking (that uses GCD under the hood, I believe).
Here is a good read on using NSOperationQueues (that uses GCD behind the scenes) to download images. There is also some Github code you can check out. They have an elegant solution to pause downloads and enqueue new downloads when the user moves to different parts of your app.
http://eng.alphonsolabs.com/concurrent-downloads-using-nsoperationqueues/?utm_medium=referral&utm_source=pulsenews
Use GCD / NSOperationQueues as opposed to using NSThreads. You will have a good learning on core fundamentals and at the same time create a well architectured app. :)