Discussion Forums  >  Config Data, JSON, App Refresh

Replies: 3    Views: 132

Fred@mySkylla com
Android Fan
Profile
Posts: 5259
Reg: Oct 03, 2011
location unknow...
62,560
09/02/12 08:21 AM (11 years ago)

Proper Config file packaging in binary for the Best New User Experience

A mistakenly held belief is, "So if you have made any changes to the app from your control panel after submitting the app (binary) for publication on an app store, the app will refresh (on second use)." Well that's the rub, it's not any changes "since you submitted to the app store" but instead "it's any changes since the app was download" that triggers an update. So, it seems that you need to publish a new binary with an updated Config file every time you make a modification to the Control Panel to give new app users a up-to-date app. ********** Here's how it works: ********** You create app. You make modifications to the app. You update the BT_config.txt file You create binary (.apk or .ipa) You upload binary to app store App is published. Time passes (could be one second or years) You make a modification in the Control Panel & "Save" App is downloaded by new app user User opens app No notice to update is triggered User opens app a 2nd time No notice to update is triggered Until a new modification is made to the app in the Control Panel after the user downloads the app will never trigger a notice that "there's an update available, would you like to update". Seems like a problem. The user will never see the updated info until you happen to update the app in the Control Panel or the user being a clever app users updates on the mere possibility that there could be an update available. After app is downloaded A change in the Control Panel is made & "Saved" User opens the app for the 2nd time A notice to update is triggered. So, how do you know when user has downloaded the app to make a "save" so the app will update on 2nd opening? You can't know this without the app reporting this. But either way seems very labor intensive to do, question is how to avoid this. Solution would be to have the user update the app upon opening. How do you inform the user to update. You could post this info in the app store, but few users will read this. Solution: Info Splash Screen tells user to update. Problem: User sees this out-dated & Ugly Splash Image eveytime they open the app. ********** SWAPPING SPLASH SCREEN SOLUTION Binary is packaged with "Info Splash Screen" ***Important*** 2nd (non-instructional) Splash image must be packaged into the binary or use image via URL Then using the Control Panel the instructions splash image is replaced with non-instructional Splash image. If submitting to Apple's App Store complete this step before the app is reviewed by Apple App is uploaded to app store. App is published User downloads the app. User see instructions splash image with need to update info. User updates (refreshes apps data) New Config data is downloaded & stored in localStorage New Config data now has different image (non-instructional image) used in Splash Screen App uses new Config data. User see new splash image. Problem solved. ********** HOW-TO ********** So, package app (binary) with instructions splash image) Make modification in Control Panel to Splash Screen to use 2nd non-instructional splash image. ********** Alternative is package binary without using Instructions Splash Screen Image Have opening "Home Screen" be a Welcome & How-To use app screen. The home screen informs user of need to update. You could explain this is especially necessary due to dynamically evolving events such as a Music Festival. Then after the binary is created, replace the home screen Add Splash screen of you wish (could be done before the binary was created, it makes no difference) When user update initial home screen is gone & new home screen is displayed. New Config data could move "Instructions Screen" to a help section or delete it entirely. Apple may reject app due to use of "placeholder text" in app. You then need to explain to the reviewer that it's not "placeholder text" but instructions. If the instructions are well written it shouldn't be a problem. The app should function and flow well as packaged. The reason app with old Config data are rejected it's not that the Config data need to update to deliver current info, but their rejected because the Config data packaged in the binary is to a partially built app. Fred
 
MadRod
Aspiring developer
Profile
Posts: 1853
Reg: Apr 12, 2012
Lisbon
27,930
like
09/02/12 09:09 AM (11 years ago)
Nice Fred, thanks. One question, but if you have a remote config file, (that I learned from you how to use), if I keep updating the remote file, the user always gets the last updates, even if its a new update made before he downloaded the app. Right? Cheers.
 
Fred@mySkylla com
Android Fan
Profile
Posts: 5259
Reg: Oct 03, 2011
location unknow...
62,560
like
09/02/12 09:29 AM (11 years ago)
Correct, by combining this method & the remote Config file method you have the "Best Method". This method only addresses the "New app user" problem. The remote Config file method deals with "User experience during app updates" problem. http://www.buzztouch.com/forum/thread.php?tid=8C9947BD787B15FB24CDBF4&command= Fred
 
Susan Metoxen
buzztouch Evangelist
Profile
Posts: 1706
Reg: May 01, 2011
Hopkins, Minnes...
26,260
like
09/02/12 08:45 PM (11 years ago)
Great ideas! Thank you for writing this up! I agree with you on the App Store....since it is designed to give the user instructions the first time it is used, it should be ok. Lots of apps give instructions the first time ou open it. We could use a plugin for this. A splash screen that just appears the first time the app is opened.
 

Login + Screen Name Required to Post

pointerLogin to participate so you can start earning points. Once you're logged in (and have a screen name entered in your profile), you can subscribe to topics, follow users, and start learning how to make apps like the pros.