Latest articleshttp://monkeysource.co.uk/blog MonkeySource Read the MonkeySource Company latest blog post. Developing MUBI for Rokuhttp://monkeysource.co.uk/blog/developing-mubi-for-roku blog/developing-mubi-for-roku Fri, 20 Jan 2017 00:00:00 +0000 iOS and Android SDK Comparison Part 1http://monkeysource.co.uk/blog/ios-development-versus-android-development blog/ios-development-versus-android-development Tue, 11 Nov 2014 00:00:00 +0000 Android Runtime (ART) vs Dalvikhttp://monkeysource.co.uk/blog/android-runtime-art-vs-dalvik blog/android-runtime-art-vs-dalvik Thu, 18 Sep 2014 00:00:00 +0000 About Phone, and tapping on Build Number 7 times. Then when you click back to Settings you should see a new option Developer options where you can switch runtimes.]]> best and brightesthttp://monkeysource.co.uk/blog/best-and-brightest blog/best-and-brightest Thu, 18 Sep 2014 00:00:00 +0000 Making Android Apps More Accessible with TalkBackhttp://monkeysource.co.uk/blog/making-android-apps-more-accessible-with-talkback blog/making-android-apps-more-accessible-with-talkback Thu, 18 Sep 2014 00:00:00 +0000 There's still a lot more that could be done to make the app fully accessible, and I'd love to hear any ideas you have?But as a start we should all being doing the basics to make our apps more accessible. I know I will be in the future.]]> The Best Apps of 2013http://monkeysource.co.uk/blog/the-best-apps-of-2013 blog/the-best-apps-of-2013 Thu, 18 Sep 2014 00:00:00 +0000 Pocket Parking Coming Soon!http://monkeysource.co.uk/blog/pocket-parking-coming-soon blog/pocket-parking-coming-soon Wed, 17 Sep 2014 00:00:00 +0000 If you want to be notified when we launch, sign up here:-http://www.pocketparking.co.uk]]> Using Android Studio and Gradle to build Android packages for both Google Play and the Amazon App Storehttp://monkeysource.co.uk/blog/using-android-studio-and-gradle-to-build-android-packages-for-both-google-play-and-the-amazon-app-store blog/using-android-studio-and-gradle-to-build-android-packages-for-both-google-play-and-the-amazon-app-store Wed, 17 Sep 2014 00:00:00 +0000 google app engine to host a static sitehttp://monkeysource.co.uk/blog/google-app-engine-to-host-a-static-site blog/google-app-engine-to-host-a-static-site Mon, 03 Jun 2013 00:00:00 +0000 New Application...In the dialog below change mystaticsite for the id of the application you registered at https://appengine.google.com/ and hit create.![new app screenshot](/assets/images/old/newapp.png)This will create a skeleton project in the directory specified.###Modify to serve static filesBrowse to the project directory and do the following:-* Delete all files except app.yaml * Create a directory called static * Copy your site files into the new directory called staticHere’s how it should look.![file structure screenshot](/assets/images/old/appfiles.png)Now edit the app.yaml file to the following, chaging the application id on the first line to the application id you’ve registered.application: mystaticsite version: 1 runtime: python27 api_version: 1 threadsafe: yeshandlers:- url: /(.*.html) static_files: static/1 upload: static/(.*)- url: / static_files: static/index.html upload: static/index.html What we’ve done here is to tell app engine to upload all files in the static directory as static files, and route html requests to the static folder. We’ve also routed / to index.html as this won’t happen by default. If you have sub-directories in your site, such as a directory called styles for css files you’ll need to add the following to app.yaml, and so on for each sub-directory.- url: /styles/(.*) static_files: static/styles/1 upload: static/styles/(.*) ###DeployThat’s it, you’re now setup to deploy your site to GAE with one click. Launch GoogleAppEngineLauncher and click Deploy. If your id is set correctly and registered it should deploy and be hosted at (swapping mystaticsite for you app id):- http://mystaticsite.appspot.com/###What’s nextYou can learn how to administer your app, including version control, and custom domain names from the docs here https://developers.google.com/appengine/docs/adminconsole/index]]> get paid, go brokehttp://monkeysource.co.uk/blog/get-paid-go-broke blog/get-paid-go-broke Thu, 02 May 2013 00:00:00 +0000 *Why paid apps are no longer sustainable for developers and what are the alternatives?*It used to be simple. Have a good idea, create an app, and sell it. OK, much digital ink has been spilt on how difficult it is to write a good app, and then get it found in the overflowing app stores. But if you actually make a successful app, and you top the charts it's time to finally post that resignation letter, right? Not so fast!Take a moment to think a little down the line:* Do you plan to release updates? * Do you have any frictional costs after the sale?Most developers will answer yes to both. You really need to be releasing regular updates to keep your users happy, and most apps now have some server side element, an ongoing cost to you. Whereas a customer used to be added value to the company, now they can easily be a burden. For example, to keep that customer satisfied they expect future updates and releases. They also continue to use your server each time they use the app. But who's going to pay for this after the initial purchase price has been used up, and you likely sold for less than a price of coffee, so it soon will be. The answer is future customers, smartphone sales are exploding, you'll be fine. Sound like a Ponzi scheme, it is! The problem is a perfect storm of a few variables. Firstly, app store discovery is truly broken, so an inevitable race to the bottom with prices ensued. Secondly, smartphone sales are exploding, and we're still a long way of saturation point. Therefore, for the time being the Ponzi scheme is still intact. Thirdly, app stores promote this model by not allowing the sale of updates, you need to release it as a new app and have no way to discount it to existing customers. Lastly, a certain fruit based app store doesn't even class them as your customers, so you can't even contact them with future products of interest![London Undergound](https://play.google.com/store/apps/details?id=com.visualit.zuti.londonUnderground) is a good example (disclosure: MonkeySource develop the Android version for Visual IT), where they took a two pronged approach. Sell the app for a fair price, and give the same app away for free with adverts to support. Interestingly, releasing the [London Underground Free](https://play.google.com/store/apps/details?id=com.visualit.tubeLondonCity) actually increased sales of the paid app (again it's exactly the same app, just without the ads). But more interesting, Visual IT are now seeing that the paid app isn't sustainable. Customers paid £1.99 and will continue to receive updates (about 6 a year) for the lifetime of the app. Hopefully, a long time! Plus, paid users are the heaviest users and hit the server daily. So they've now got the situation that the users of the free app are subsidising the paid users, and it's the free app that will keep the development funded. Kinda freemium, but on it's head!So before releasing that new app, think carefully about the long term viability. It's tempting to stick a price on it and hope the market keeps growing. But this can't happen forever, so ask yourself will you gain value from the user who's still using your app five years from now, or will that become a burden you can't truly afford? As they say, good things come to those who wait.]]>