Rotate your phone

Once that’s done you’ll be able to experience the FieldMotion website perfectly.

22 Sep 2015

Dynamically Updating App Scripts

in Technical Blog by Kae Verens
Dynamically-updating-app-scripts As any person who develops apps will tell you, the most painful part is when it leaves your laptop and is uploaded to the various app stores. In the case of Android, the Google Play Store takes an hour or two for the app to propagate, but in Apple\'s case, the average wait is a whole week. This can be incredibly annoying; especially when your upload is an emergency fix for something which could potentially cause problems. We\'ve experienced it, and no amount of cajoling, praying, or bribery will make it go any faster. To alleviate this problem, we\'ve come up with a new method that will leave the propagation in our own hands, meaning that there is no waiting at all - when we release a new update, it is downloaded to our app within seconds. Not only that, but the downloaded code is actually more secure than if it were part of an app bundle. Also, we can target /who/ gets the updates. We can target, for example, a specific company, or a development team, or a specific person or device. Ok, so how? I\'m not going to share the actual code, but will describe the method we use, so any development team can replicate what we\'ve done. Well, we start out with a tiny "core" app, which is distributed via the app stores. This core rarely needs to be updated, so it doesn\'t matter if it takes a week or a month for it to get through. Upon first start-up, the core downloads a "login" script from our mobile server. This script simply shows the login screen and lets a person log in to their FieldMotion account. After logging in, the script then downloads user-specific scripts, and checks constantly from that point forward for any new scripts. The trick is in /how/ this is done. Scripts are downloaded over HTTPS, so they are not vulnerable to man-in-the-middle attacks. The login script is generic and can be downloaded by anyone at all, so it doesn\'t matter if it can be read, but for the main app scripts, one step in security is in making it difficult for potential hackers to read your source code. Using HTTPS means that hackers cannot simply listen to your WiFi and copy down what is downloaded. When the scripts are downloaded, they are then stored in the app browser using localStorage. Because Android and iOS compartmentalise apps, one app cannot read the localStorage of another, so this is one of the most secure ways of storing your scripts so they cannot be read even if someone has access to your phone. Once a person has logged in, you can then send them the scripts that are specific to them, depending on the groups they\'re in, etc. To keep their scripts up-to-date, you can set up a long-poll which constantly checks for new scripts to download. In the case of people that are using "stable" code, you can change this to a relatively delayed (every 30 minutes, for example) short-poll because it is less resource-intensive on the server side, and stable code doesn\'t need to-the-second updates. Another benefit to this method is that you no longer need to compile your code for each phone. It can take a few minutes to install new code on the Android or iPhone. This can be very annoying if it\'s just a one line change you want to test. With this method, though, you could do your development on-line using a code editor such as Code Mirror, and have it pushed to your test phones as soon as you click Save. If happy with the code? Just push it to a release group for your users. To summarise, the main benefits of developing your apps this way are:
  • Dynamic upgrades on /your/ schedule
  • Code is more difficult for hackers to analyse
  • You can decide who gets what scripts
  • No compilation needed anymore - just test and release
  [divider scroll_text=""]