As anyone with an iPhone knows, some applications launch quickly, while others take several seconds.
What are the best techniques for ensuring an iPhone app launches and becomes usable in a snappy manner?
Apple recommends you "lazy load" every view. I.e. only load the first page on start up, and other pages only when they are navigated to.
In terms of graphics, use PNGs wherever possible as the device is heavily optimized for this format.
Also include the startup screenshot so the user knows the application is loading.
I use lots of external resources, so I use Lazy loading to get up and running quickly. This way the APP can start with the barest minimum and then load the rest while its already begun.
Made a big difference in start time
This is one of those things where there is no sure-fire path to success. Use Apple's excellent Instruments tool to monitor your application's launch. You then need to delve into the results to figure out ways to optimise the launch process.
Also try profiling with Shark, to find any performance bottlenecks.
http://developer.apple.com/iphone/library/documentation/DeveloperTools/Conceptual/SharkUserGuide/Introduction/Introduction.html
Related
I'm designing an iPhone application and writing a paper on it. I was wondering how I can see how much virtual/real memory my application will take in the iPhone. I am currently running it in the simulator.
No, this cannot be done accurately. You can get consistently good values for most of the APIs you use using the Allocations instrument, but there are differences in execution environments which make exact figures impossible.
Yes, you want to Profile you app. In Xcode, hold down the "Run" button and select Profile. A window should pop up asking you to select an Instrument to profile your app with. For memory usage, you can analyze your apps using either Allocations or Leaks. I would do some googling for instructions on how to use these two instruments.
I am new to ios development and doing development in ios4.0.1 and xcode 3.2.3. My application should capture other application's launch time and (close) end time. how can we do this? Any help will be appreciated.
Thanks
Pushpa
For apps in the app store, the answer is "You can't". The best way to think of other applications on iOS with respect to yours is: don't. You can't access their data, you can't see if they're running, you can't control them, and you can't change them. Apps are well and truly sand-boxed as a fundamental design decision in the current setup.
About the only thing you can do is trigger their launch with a suitably formatted system URL. If a Wikipedia application has registered the scheme wiki, you might be able to launch and communicate some simple data by having the system load the URL wiki://articleName, but that's the limit. You don't even know what application will be launched, only that one has the wiki handler.
Jail-broken iOS systems are a whole different matter, but I'm assuming you're not working on those.
I know with ios 4 it is possible to run application in background as per this documentation
http://developer.apple.com/library/ios/#documentation/iphone/conceptual/iphoneosprogrammingguide/BackgroundExecution/BackgroundExecution.html
this documents states that if application updates user's current location in background continuously then it is possible to run it in background.but is it necessary that we have to use only CLLocationManager for updating current location?can we user other apis like google latitude apis for updating current location?then also it is possible that application is able to run in the background forever?
As far as I understand from the document you posted, if you define the UIBackgroundModes with a value of location in your info.plist, "the system should allow the application to run as needed in the background". So, the first answer is yes, the application can run in the background and it will run indefinitely (up to battery life). This could be easily checked, actually.
Anyway, it seems to me that this kind of functionality is "reserved" to GPS-like apps and that Apple is really concerned about its usage:
For applications that require more precise location data at regular intervals, such as navigation applications, you need to declare the application as a continuous background application. This option is available for applications that truly need it, but it is the least desirable option because it increases power usage considerably.
so, I understand that Apple will screen really thoroughly all apps that activate this mode in order to assess if they really need the continuous update or do not (and in this case, possibly, the app would not be let in into the App Store).
Now, to answer the second part of your question, I think that one way that Apple will know if your app really complies with the rules, is its usage of CLLocationManager. The risk is that if you use another service, then Apple could think when reviewing your app that you just need background time without needing to constantly update the location.
But this is just a guess...
My app takes a long period of time during the startup, while the splash screen is shown. I assume that It is so due to the size of what the iOS has to load, including libraries. My question is, can I load those in the moment the user actually wants to use it, so it makes the startup time shorter?
Are there other ways to do it shorter?
Thanks a lot.
All 3rd party libraries are statically linked to your app. In theory you can lazy load only Apple's own weakly bound libraries. I am not aware how you can control this process on iOS. It's certainly possible on Mac.
sure you can as long as you don't need them directly.
LazyLoad is not limited to what you apply it too, for example if you have a huge Opengl scene you can chose not to laod its textures until the user actually click on the button you need.
The downside of this is that the waiting time to open whatever requires a lazyload will be moved further down the app (when the user wanted to play he will have a longer loading time).
What you could try is to launch Thread that handles the loading at startup and from the thread you do a setBooleanLibXFinishedLoading this way your app will only have to wait for all the booelan to be set to proceed.
This should reduce the apparent waiting time for the user while optimizing the time actually spend loading.
hope this helps
Jason
What is the biggest limitation of making/using webapps?
I'm thinking that when you use localstorage, offline-browsing and geo-abilities thaht you get from html5 the differences are quite small (except for games).
The great benefit from using webapps is that they are cross-platfrom compatible!
One of the biggest limitation is access to hardware. You can't access USB ports, specialized hardware you might have (printers, bardcode readers), and other stuff, and of course, you don't have access to some very important APIs that you need today to run games (DirectX, OpenGL).
But I agree: every day they are fewer reasons to not go with a WebApp instead of a Native APP.
For iOS: When using geolocation for webapp, the user will get prompt about giving location access every time, which could be annoying for the user. Native app, only the first time.
The UI performance is also not as smooth as native. Scrolling in webview has a "slower" acceleration compared to native view scrolling.
Performance is one major difference. I see from around 20X to over 200X speed improvements when converting from Javascript to compiled C/Objective C code. One can also do real-time audio and video processing in native code, as well as low-level networking, etc.
One interesting limitation (HTML5-wise) I see is from a point of intellectual property. Since a lot of code (raw JavaScript + HTML) is exposed to the user, you have to carefully decide which components will be "open" to end users. Not aware of any standard way to lock or hide your IP once it leaves your server.
Webapps are great for reaching multiple hardware devices, you can update your app a lot faster, thus feedback is quicker. However, your users will require an always-on internet connection to use your webapp, that's probably the biggest negative about them in comparison to a native (offline) app.