Addressing Distribution, UI and Performance of Mobile Apps
Upcoming SlideShare
Loading in...5
×
 

Addressing Distribution, UI and Performance of Mobile Apps

on

  • 833 views

 

Statistics

Views

Total Views
833
Views on SlideShare
833
Embed Views
0

Actions

Likes
0
Downloads
5
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • There are obviously many more challenges involved in the development of mobile applications. They can be - say a human error… The developer does not understand the business objective behind the application or maybe that there is disconnect between the idea and execution. This level represents the early stage applications that support only limited devices and geographies. At this level, the more focus is on quality mobile application development , which covers basic need of mobility like good UI design , effective interrupt & memory management with this the focus on distribution & certification.Even issues related to scalability and performance are also addressed.Following our best practice ensures that all the parameters and their implications for a given set of mobile requirements are handled adequately and at the right time. Adopting this model while designing and creating a mobile application helps layout critical expectations, enabling design and development in sync with the features that really matter.
  • It is imperative that the applications UI design and flow should cover business needs effectively and deliver quality user experience in terms of interface & design. The UI should be compatible to the native applications so that the user finds them easy to use.
  • Application suspend and resume should be handled properly especially for incoming call and SMS alerts.All the UI and media stuff like images, sounds, context pointers should be released on SUSPEND event.Low memory notification should be given highest priority and unused memory should be related immediately.Suspend routine should be small and should not be time consuming.Object Serialization/De-serialization and state management.Context sensitive handlers will execute data processing in case of interrupt handling.Thread safe execution of processes so that all UI thread will be in sleep state until interrupt executed.
  • At the time of allocation we need to handle it in such a way as to avoid memory fragmentationMemoryfragmentation rules use memory allocation with power of 2.While using tile patterns for images, applications should not use bigger tile images where patterns are duplicating. Instead of this, application should use a small tile image and then at runtime, it should be copied at required places.Application should make sure of using FREE for every allocation. Application should not throw any memory leaks as after multiple time usage of application, device could start behaving abnormally.Memory management should also adhere the guidelines of the corresponding OS. Like in case of iPhone, it should follow complete guidelines for using AUTORELEASE POOL.If application wants to store a received object completely in an instance variable then it must retain or copy it. It should generally not use Weak References.Objects created by application should immediately free if that is no longer needed.Application should always decide where it would require Deep Copy of objects and where it would require shallow copy.All resource intensive data should be loaded lazily.Bigger chunks should be allocated from Heap and should be released immediately after use.To avoid memory fragmentation, memory should be allocated in multiples of 2.On iPhone, local auto release pools should be used.Application should not cache heavy data on stack.At the time of allocation we need to handle it in such a way as to avoid memory fragmentationDo not create objects in bulk, minimal/limited number of objects should be used.Objects creation should be timely and any kind of object should not created in advance.All files and stream objects should be closed properly and timely.All exceptions / memory warnings (on iOS) must be handled properly.Use Lazy loading of resources and avoid frequent loading of resources.Class member functions should not be longer than 50 lines.Instead of BMP always use PNG.All kind of failure conditions must ne handled properly across all the member functions.Do not use multiple font strips(>2) in one application (Specific to J2ME / BREW)Probably we could write more points for memory management. Example:Suppose there is an situation where application wants to allocate memory of 15 bytes. In this case, application should actually allocate 16 bytes (2 power 4). When garbage collection comes into the picture, it would be much easier at that point of time to remove 16 bytes as compare to 15 bytes.If application have to display lot of images in the applications, then instead of using BMP, application should use PNG.We have to identify various certification needs of the target platform like at the design time and put in such considerations: The application should support seamless resume after incoming call or SMS.It should have the Exit options on all screens in every flow. Applications should follow the guidelines requirement of the corresponding signing authorities like NSTL for BREW, Symbian Signed for Symbian, Java Verified for J2ME, App Store HIG for iPhone. Application should be compliance to desired guidelines:Cost associated with certifications should minimized by creating single builds for multiple devices. Advantage of creating single build is to reduce the maintains cost and can easily adhere  to change requests. Example:All BREW applications should have functionality of the CLR key as a BACK key.In case if your Symbian application support Auto Start feature then there must be an option which allows the user to enable/disable auto start functionality.iPhone OS defines the standard appearance of user interface elements, and delivers consistent behaviors that users expect. Same mechanism should be delivered in all iPhone applications so that user could easily understand the applications.
  • At the time of allocation we need to handle it in such a way as to avoid memory fragmentationMemoryfragmentation rules use memory allocation with power of 2.While using tile patterns for images, applications should not use bigger tile images where patterns are duplicating. Instead of this, application should use a small tile image and then at runtime, it should be copied at required places.Application should make sure of using FREE for every allocation. Application should not throw any memory leaks as after multiple time usage of application, device could start behaving abnormally.Memory management should also adhere the guidelines of the corresponding OS. Like in case of iPhone, it should follow complete guidelines for using AUTORELEASE POOL.If application wants to store a received object completely in an instance variable then it must retain or copy it. It should generally not use Weak References.Objects created by application should immediately free if that is no longer needed.Application should always decide where it would require Deep Copy of objects and where it would require shallow copy.All resource intensive data should be loaded lazily.Bigger chunks should be allocated from Heap and should be released immediately after use.To avoid memory fragmentation, memory should be allocated in multiples of 2.On iPhone, local auto release pools should be used.Application should not cache heavy data on stack.At the time of allocation we need to handle it in such a way as to avoid memory fragmentationDo not create objects in bulk, minimal/limited number of objects should be used.Objects creation should be timely and any kind of object should not created in advance.All files and stream objects should be closed properly and timely.All exceptions / memory warnings (on iOS) must be handled properly.Use Lazy loading of resources and avoid frequent loading of resources.Class member functions should not be longer than 50 lines.Instead of BMP always use PNG.All kind of failure conditions must ne handled properly across all the member functions.Do not use multiple font strips(>2) in one application (Specific to J2ME / BREW)Probably we could write more points for memory management. Example:Suppose there is an situation where application wants to allocate memory of 15 bytes. In this case, application should actually allocate 16 bytes (2 power 4). When garbage collection comes into the picture, it would be much easier at that point of time to remove 16 bytes as compare to 15 bytes.If application have to display lot of images in the applications, then instead of using BMP, application should use PNG.We have to identify various certification needs of the target platform like at the design time and put in such considerations: The application should support seamless resume after incoming call or SMS.It should have the Exit options on all screens in every flow. Applications should follow the guidelines requirement of the corresponding signing authorities like NSTL for BREW, Symbian Signed for Symbian, Java Verified for J2ME, App Store HIG for iPhone. Application should be compliance to desired guidelines:Cost associated with certifications should minimized by creating single builds for multiple devices. Advantage of creating single build is to reduce the maintains cost and can easily adhere  to change requests. Example:All BREW applications should have functionality of the CLR key as a BACK key.In case if your Symbian application support Auto Start feature then there must be an option which allows the user to enable/disable auto start functionality.iPhone OS defines the standard appearance of user interface elements, and delivers consistent behaviors that users expect. Same mechanism should be delivered in all iPhone applications so that user could easily understand the applications.
  • Effective Distribution strategy  plays a very important role in success of any mobile application product. As applications distribution directly affects billing methodology hence it’s very important to be considered at the time of design only. Applications nature decides type of distribution, typically consumer mobility applications may be distributed via App stores, carrier deck or app aggregators like (get jar & cell mania etc). For enterprise mobility, corresponding Mobile Device Management system should be planned and configured according to expected load. If the application is a client/server application which needs frequent interaction with client (mobile banking or stock market transaction), you may feel the need of distributing it from your own Deck i.e. Over the Air, from your own Website, as it becomes difficult in these types of app to share the revenue with carriers, aggregators and store fronts along with providing quality service to your customers. In setting up of OTA distribution infrastructure for these cases, we need to take care of two things:Auto-detection of device platform and model, so that the right build is delivered to the requesting mobile device – this is achieved by searching the WURFL database using user-agent string fetched from the mobile request.Auto-upgrade: infrastructure is required on both the client & server side, so that on every login the server can compare the client build version with one available on OTA server and give notification of optional/mandatory upgrade to the client app. Example:To Explain this further, let me take an example of our application related to the commodity market – called “Mandi Bhav”. We have developed this application in various different platforms like iPhone, Android, Blackberry and J2me . For Mandi bhav our OTA server detects device platform & device model from the incoming download request and redirects/delivers it the matching build. And when we came up with some new features of trading which was made available as optional upgrade for end-user –a message was displayed to the user on every login which they were allowed to skip – while once we updated the client for optimized communication when we even modified the core data sync API’s, at this time we made the upgrade as mandatory and the client user did not have the option to skip the upgrade which was forced as auto-upgrade. 
  • What if your killer idea was designed & developed well but when it comes to using the application the performance of application is poor. Because of this even you are loosing your valuable customers.Performance optimization is always a key to success for a mobile application, because if the application does not perform well there are chances of loosing the customers for sure.Performance should be monitored and controlled all the time as there are limited resources available on the device. Mobile applications should be designed carefully and employ every possibility to improve performance. Application size should not exceed to a certain limit as specified by the corresponding OS and target device spec’s. it often vary from OS to Os , On some of the OS, the file & database operations are very slow, so they must be performed in background worker threads.Application should avoid long and tight loops, should avoid battery consumption as to not use GPS continuously in our application. If there is a requirement of using GPS then application should use some customized algorithm for GPS. Even excessive use of threads should be avoided in the application and network or file IO request should be queued and we should maintain proper synchronization among various threads. One should always try to release device resources if application is not doing any operation or is move to background due to system interrupts.one should use Switch case instead of If else for long list of checking items and avoid long and tight loops.Another consideration is related to image usage & memory fragmentation. These aspects should also be considered while designing a mobile application. And if considered you will see the improved performance of the application.

Addressing Distribution, UI and Performance of Mobile Apps Addressing Distribution, UI and Performance of Mobile Apps Presentation Transcript

  • Addressing Distribution, UI and Performance of Mobile Apps
    By
    Impetus Technologies
    Recorded version available at:
    http://www.impetus.com/webinar_registration?event=archived&eid=25
  • Agenda
    Mobile Maturity Model
    Best Practices
    Graphics and UI Design
    Interrupt Handling
    Memory Management
    Certification
    Distribution
    Performance
    Reliability
    Case Study
    Recorded version available at:
    http://www.impetus.com/webinar_registration?event=archived&eid=25
  • Mobile Maturity Model
  • Mobile Maturity Model
  • Graphics & UI design
  • Interrupt Handling
  • Memory Management
  • Certification
  • Distribution
  • Performance
  • Case Study
  • Impetus Technologies
    Recorded version available at:
    http://www.impetus.com/webinar_registration?event=archived&eid=25
  • Questions
    Recorded version available at:
    http://www.impetus.com/webinar_registration?event=archived&eid=25
  • Thank you
    For more information,
    write to us atinquiry@impetus.com
    Recorded version available at:
    http://www.impetus.com/webinar_registration?event=archived&eid=25