Mobile cloud sync
Download as PPTX, PDF1 like395 views
The document addresses essential factors for cloud-based mobile app synchronization, focusing on smart usage of disk space, network, and battery resources. It outlines a comprehensive synchronization strategy for both cloud-to-device and device-to-cloud interactions, highlighting event-driven and on-demand sync methods. Recommendations for efficient data handling, offline mode functionality, and user-specific settings synchronization are also discussed.
Mobile cloud sync
- 1. Synchronization Architecture for Cloud powered Mobile Apps Prithiviraj Damodaran www.ByteContinnum.com
- 2. Major Concerns Addressed 1 of 2 From the App User and Device Resource view point the following are some of the critical factors a cloud backed mobile engineering team should consider. • Smart Disk space usage - A lot of apps including some popular social media apps abuse device disk space. Every time the apps sync with the cloud counter part they bring down fresh data. Apps should be considerate of device user and should come up with some clean-up mechanism.
- 3. Major Concerns Addressed 2 of 2 • Smart Network usage – Be it upstream or downstream sync i.e. apps as well as the cloud counter parts should be designed to be very frugal about the number of bytes sent over the wire as well as the number of network calls as it directly impacts the data usage and hence the device user. • Smart Battery consumption - For instance • Apps which broadcast real time user activities should smartly club syncs to reduce multiple device pings • Location and geo fence based apps should use the right strategy to avoid draining device battery.
- 4. Event Driven Synchronization Cloud-2-Device • On-AppStartup • On-AppBackground2Foreground Transition • On-AppSignin (if any) • On-Demand user action Device-2-Cloud • On-AppUITransition
- 6. On-Start-up - online • First time fetch of current Location • Instantiate N/W Connection receiver. (Wifi/Data) • “All” data if new device or “Newer” data deals since last sync date, if used device. • Clean up older disk cache records. (Cache date < Current date and un synchronized) • Any other Metadata sync or change in Business rules or disclaimers etc..
- 7. On-Start-up - offline • If new device change to offline mode and provide an option to retry N/W connection • Active fetch of current Location. • If used device use last synced data • Clean up older disk cache records. (Cache date < Current date and synched)
- 8. On-Sign in • User data later than last sync if already used device - Something like getting the newer emails from the server since last sync. Using the app in Multiple devices doesn’t affect this part of the sync. But it does affects the synch of user specific settings/ preferences. • User specific notifications – offers or expiry notices etc. Since there could be multiple devices in which user could login from, every device will have to maintain last sign in timestamp and Cloud will maintain last synchronization timestamp at levels desired. Every time during sign-in If these 2 time stamps vary then it calls for Synching all user specific settings data • User specific app settings and preferences
- 9. On-Sign in - offline • show the message and continue as guest in offline mode.
- 10. On-Demand Sync – 2 Way • All data listing screens shall support on-Demand sync. Using a pull down or swipe down gesture user can initiate sync. • During swipe down n/w state will be first checked before making the Sync call. If offline appropriate message shall be shown. Best real life example would be your Gmail app. Try to “star” an email and Swipe down. Your “star” should reflect in your server (try and open gmail in another device or PC) and if you had new emails that would be in your device too. So 2 way cloud sync.
- 11. On-Demand Sync – 2 Way 1 2 3 Rest APIs
- 12. Device-2-Cloud
- 13. On-UITransition • All user activities shall be stored at disk first and synced on the next UI based action like a UI Transition. The approach is disk first and asynchronous calls to cloud. The stored data shall look something like below. Choice of storage could be disk caches like SQLLite or something similar. Data Cache Date Sync Status {“test”:”data”} 2014-08-01:00:00:00 Sync Progress {“test”:”data”} 2014-08-01:00:00:00 Sync Complete {“test”:”data”} 2014-08-01:00:00:00 To be Synced
- 14. 1 2
- 15. Offline mode As a part of the strategy make sure all deal breaking features (whichever possible) are supported in offline mode for the success of the app. This might require some careful planning and some extra processing / storing required data in the device.