I’ve decided to move the majority of my content over to my Programming Thomas blog instead of this one because it fits better with my other projects. Please go over there for any updates to my apps and general programming information.
Posts tagged ‘programming’
This morning I remembered a program that I haven’t used in years: Pivot Stickfigure. The program was a pretty simple animation tool for making 2D stickfigure based animations and it was fairly popular a few years back and there are many thousands of videos that have been made with it on YouTube. I thought it would be interesting to make a similar tool to Pivot Stickfigure that allowed me to create simple animations, however I figured it would be more interesting if I made it with HTML5 Canvas.
The above video shows my shocking first attempt at making an animation. Unfortunately my computer’s least favorite activity is screen capture so its a bit slow but if you want to check out the web app please click here and if you want the JSON for my animation click here (you can just copy and paste it in).
Android is a good platform – not a great platform, but a good one. I’ve been doing a lot of Android development recently and it certainly has many good features and it is easy (and cheap) to make an app for the system. There are, however, a great number of problems with Android from a developer’s point of view. This is a rough list of things I would like to see from the Android project. I don’t think that it necessarily needs them, but I think it would be a good thing for the platform if it had a few of them:
- SVG support everywhere: A major problem with Android at the moment is that you have to create at least three different copies of the same icon for use in app because Android apps can run on many different devices at different resolutions. If all icons were changed to SVG it would be possible to just include one copy of the icon and know that it would be shown at maximum quality on all screens. This would also be useful when Android displays eventually get to a higher pixel density (as in the iPhone and iPad) as icons would never appear pixelated. SVG font support would also be handy but not a requirement.
- Better font support: Android currently comes with three fonts whereas Windows Phone and iOS come with over fifty. You can include fonts in your app however if you wish to do this you have to change the font of each View pragmatically rather than via styling or XML which can increase the size of the app and also make it slower. Again, SVG font support would be useful.
- Higher PPI displays: When the iPhone got a Retina Display the only way that Android devices could get a similar resolution was to get bigger screens because Android wouldn’t run as well on higher density displays. There should be some big system changes to get this support.
- One Android: It amazes me how phone manufacturers have fragmented Android by adding new UIs and alternative apps. Whilst some of these are really great it often means that some devices won’t receive a major update for months after it has been released because the UI is being developed. If Android could go back to being pure Android it would make it a lot easier for developers and require less testing of apps.
- Google Play gift cards: This seems like a painfully simple thing to do but it is one of many reasons why iOS developers make a lot more than Android developers. It is a well known fact Android users ‘don’t like buying apps’ however the problem is that most of them can’t. When you set up an iTunes account you either have to type in your bank details or set it so that you will use gift cards however this is not required for Google Play registration. As most Android users have not created a Google Wallet account they can’t buy Android apps. By selling gift cards everywhere (as iTunes does) more people are likely to start buying apps.
- Better integration between Eclipse and Google Play: Currently you can create an app in Eclipse, export it and then upload it to Google Play. It makes a lot more sense, however, to integrate the two so that developers sign into Eclipse and then press one button to upload an app to Google Play. This would also simplify the process of creating in-app purchases.
- OTA updates: Most iOS devices are now running iOS 5.x and many are already running iOS 5.1, which came out in the last month. On Android most devices are still stuck with a two year old version of Android because phone manufacturers (who are responsible for updates) have not chosen to update to Ice Cream Sandwich. If Google were to take over the updating of Android devices it would probably mean that more people were using the latest version of the software.
- Better emulator: The Android emulator is very good however it can be incredibly slow when trying to emulate Android 3.x and Android 4.x devices.
App development is becoming increasingly common and everyday hundreds – if not thousands – of new apps are released each day. Mobile platforms, along with the web, are the most popular deployment bases. The main mobile OSes all offer an online app store of some sort that allows developers to either give away their apps for free of force users to pay for them.
A large number of apps are now ad-supported so that developers can still profit from free apps. The only problem with this model is that ads often really damage the user experience, especially in games because they just get in the way of what the user is trying to do.
The biggest alternative to ads without charging for the app is to have in-app purchases so that users have to pay for additional features in the app. This is a lot more efficient than ads because it maintains a contained user experience that is solely focused on the app itself. My belief is that these in-app purchases should add to the user experience rather than not having them making the app worse. An app with in-app purchases should function perfectly reasonably without the user having to pay to make it better – instead they have the choice. At the same time I’ve got absolutely no objections to users being encouraged (but only subtly) to purchase additional features.
At the end of the day if you’ve made a really great app you should charge for it but if you feel you can reach more users by making it free and letting them pay for some extra features in-app purchases are probably an equally good if not better option.
After that I’ve made a mental note not to try posting from the WordPress iOS app.
There are probably hundreds of thousands of great smart phone apps out there that are still waiting to be made for tablets. This year (more than 2010 and 2011) will be the year of tablets as millions of people buy iPads, Android tablets and Windows 8 tablets. The first two will happily run iPhone and Android phone apps respectively however there will be a little more conversion between Windows Phone 7 apps and Windows 8 apps but I should imagine that the process will be roughly the same.
The current problem is that phones are generally a lot smaller than tablets and also have different aspect ratios. For instance, the iPhone has a resolution of 960 by 640 and an aspect ratio of 3:2 whereas the iPad has a resolution (currently) of 1024 by 768 and an aspect ratio of 4:3 thus meaning that apps’ layout can’t really be the same on both.
The first method of converting an app is to literally scale up the layout so it looks exactly the same on both screens. It may be that some zooming is required on a phone whereas it isn’t on a tablet as in Safari. This method will work for some apps, but it won’t work with all apps. Here is an alternative method where you get two screens of phone information on one tablet screen:
An alternative option that works similar to the above is to split the single column that you have on the phone layout into two columns on a tablet. The above example wouldn’t really work but if you had a biography app you could do the following:
In this example the content on the phone has to scroll whereas on the tablet some of the information can be put on the left hand side in such a way that it would never need to scroll however the remainder of the information could be placed on the right of the screen and would, if necessary, scroll.
Obviously it may be necessary to reverse engineer this process and convert a tablet app to a phone app. This is probably a little more challenging as you are naturally given more space, as a developer, to work with on a tablet whereas that space becomes limited on a phone. I would recommend taking advantage of scrolling/flipping, tabs, menus and other specific phone features to ensure that the information is still on the screen.
If you’ve ever worked with Android development before you’ll probably know that once you get it right it can be incredibly rewarding however if you get it wrong it can be a real pain to fix. Sometimes the development also demonstrates the fragmentation of Android and how it can be a great challenge to do something relatively simple because it works differently on different devices.
I recently developed the Keep Calm app for Android that allows users to create Keep Calm and Carry On style posters. The app has been a reasonable success (20,000 downloads in a month) however there has been one major issue: not everyone could save properly. At first I didn’t really understand why this was because all of the testing I had done indicated that the Bitmap object that the image was stored in was being correctly saved to the SD card and it would then appear in the Gallery app. However, this was not the case for everyone.
I soon discovered that it wasn’t a technical issue with my app entirely. The default Gallery app gets a list of files in the various images folders on the SD card each time it loads but the Android system doesn’t always refresh this list of files very often – sometimes only when the device is restarted. Clearly it would have been a major issue for my users to have to restart their phone each time they wanted to view a file so I came up with this solution:
String saved = Images.Media.insertImage(this.getContentResolver(), bitmap, title, description); Uri sdCardUri = Uri.parse("file://" + Environment.getExternalStorageDirectory()); sendBroadcast(new Intent(Intent.ACTION_MEDIA_MOUNTED, sdCardUri));
The bitmap object is of type Bitmap whereas title and description are both Strings. The sendBroadcast function (your activity inherit it as the class extends Activity, where the function is) then forces the OS to remount the SD card as it would do when the device starts up meaning that your picture will appear in the Gallery app. If you want to prove this to your users you can load up the file in the app:
Intent intent = new Intent(); intent.setAction(android.content.Intent.ACTION_VIEW); intent.setDataAndType(Uri.parse(saved), "image/*"); startActivity(intent);
This then loads the image up, using an Intent, in whatever the default Gallery app is. Remember that you’ll need to add the android.permission.WRITE_EXTERNAL_STORAGE to your Android Manifest otherwise the app will fail. The obvious progression of saving is, of course, sharing and Android makes this incredibly easy to do without having to use the APIs of all the various social networks that exist – instead the app can just utilize services provided by other social network apps on the phone. Here is how to do it:
Intent sharingIntent = new Intent(Intent.ACTION_SEND); sharingIntent.setType("image/png"); sharingIntent.putExtra(Intent.EXTRA_STREAM, Uri.parse(saved)); startActivity(Intent.createChooser(sharingIntent, "Share image"));
This loads up a menu (unless no options are available other than email) headed with the “Share image” text asking the user what service they would like to share it with. The appropriate app will then launch. Another cool thing I’ve done using a Bitmap is to set the wallpaper. You’ll need to ensure that the Bitmap is double the width of the user’s device and the same height (explained in this Lifehacker article) – this could be done using a Canvas. Here is the code you can use:
WallpaperManager wallpaperM = WallpaperManager.getInstance(this); wallpaperM.setBitmap(newBitmap);
Like with saving, you’ll need to ensure that you add the android.permission.SET_WALLPAPER t0 your manifest otherwise, again, the app will fail. Hopefully this article has helped you with your projects and if you have any other problems leave me a message in the comments.
I really like doing Android development and over the past few months I’ve done quite a bit of it but I found at the beginning that some things didn’t seem to be entirely logical that were quite important despite the fact that I already had a vast programming knowledge. Here is a list of things I reckon are useful for learning Android development:
- Java experience: I don’t think that you need to know loads of Java to develop Android apps but I would say it is important that you at least know the syntax and roughly how to do things. Experience in a similar language like C# or C++ would probably get you by, just so long as you know the difference between a package, class and that kind of thing
- Experience in another object-orientated language: Some experience in another language would also be useful because despite the fact that most Android development is in Java it is useful to understand how other languages do things because a lot of the Android specific Java has had influence from C++
- An understanding of how apps work: This would probably come with programming experience but you really aren’t going to get anywhere if you don’t get how the most basic apps. Reading a few tutorials can help fix this
- Basic knowledge of XML and SQLite: You won’t need to know how to do these perfectly but so long as you can create XML documents and edit them. I wouldn’t say SQLite knowledge is vital but it would be good to have some database knowledge
- A basic understanding of other mobile platforms: I had done a tiny amount of iOS and Windows Phone development before starting Android which probably helped me a tiny bit because it gives you some knowledge of design. Windows Phone development is probably more different to Android than iOS, so even if you’ve just created a calculator in iOS you’ll be in a good position to start Android development
- Good resources for testing: The emulator is good but I’ve found that it always useful to either have at least one Android device for testing. I also recommend setting up a few different devices in the emulator with different screen sizes and versions of Android because that will give you a chance to test in loads of different environments
- You’ve read some stuff on Android development: It is worthwhile reading up on Android development before you get started. Android Design and the Android Guide are both good places to start and reading some blogs will probably help develop your ideas. If you get stuck, make sure that you go on Stack Overflow.
Once you are fairly confident with all of this I recommend going over to Lars Vogel’s site which has some great development tutorials.
It turns out that this month the Microsoft C++ compiler will turn 20 and it is probably my second favorite C++ compiler after G++. Microsoft are aiming to ship C++ 11 Beta that will, for the first time, include ARM support, Windows 8 support and better parralel computing support. At the end of the day it is still good old C++ it just happens to support a lot of extra features, but yet I still prefer G++ because most of my C++ work is on Linux and G++ produces much smaller executables on Linux compared to Windows.
Obviously some compilers automatically optimize code to a certain extent so that it is as efficient in both speed and memory usage as possible and this is generally the deciding factor in how big the produced executable is. Despite this, I reckon that how good a C++ variant is depends on how good its libraries are.
Microsoft C++ with the Microsoft Foundation Classes basically lets you do pretty much anything you could possibly want on Windows however the open source community has had to build up something similar for Linux. The GTK framework is basically fantastic and I personally prefer it to the Windows stuff because you don’t have to write as much code to build complex UIs.
The cool thing about C/C++ compilers and variants is that they are pretty much all standards compliant and have the same basic libraries. Because the languages were designed to work across multiple platforms tools such as SQLite just work without having to do complex configuration of the compiler. Ultimately at the end of the day there is no ‘best’ C++ variant because they are all pretty good, I just have a personal preference towards G++ and GTK.
I spend a lot of time developing software and it means that I have to put far too much effort into designing the UI. I don’t really like UI design because I prefer the actual backend programming because it is far more interesting. I tend to be incredibly lazy when it comes to design.
Over the last few years we’ve had loads of new design technologies that have made it easier to develop great user interfaces for our applications. Microsoft adopts an XML based markup language whereas Apple still maintains its Interface Builder which hasn’t really changed too much since the last 1990s. Other systems adopt similar technologies.
I’ve recently noticed that animation has become a more prominent thing in UI design. Many smartphone apps tend to animate between screens by sliding or flipping and websites are gradually adopting animation between states. Sometimes this works very effectively but most of the time people will go over the top.
UI animation is only really useful if it adds something to the UI and doesn’t slow down the application. I am concerned that with the introduction of CSS3 and other technologies animation is going to become more commonplace as bad UI designers add it to almost everything – it will be like Flash all over again.
I personally don’t use animation at all, but that probably stems from the fact that I prefer the actual programming to the UI design. When working on projects I generally employ a 10:1 ratio of programming time to design time purely because it means my apps generally run better.
The Raspberry Pi platform is clearly going to be a large succes and I plan to buk one as soon as they get released but I can’t decide what I would use for. Obviously it would be an interesting platform to develop with but here are some interesting ideas:
- A media server – the OS would be installed on a memory card and an external hard disk would be plugged in via USB
- A web server although it would probably be a bit slow and not great at handling loads of traffic
- A cool UI for your TV (and internet if that isn’t built in)
- A drone
- Wearable computer
- Home automation
- Home surveillance
- An emulator for old video games (running a Nintendo 64 emulator would work well, I think)
- Doing some work with Arduino to produce some pretty advanced and cheap systems
- Scientific research
I think it will become clear what people like me are going to use it for when we actually get the devices because frankly I don’t think there will be anyone except programmers buying them for the first few months – it probably won’t be until September that they start appearing in schools.