UrbanThings sent our top Android guy to this year’s DroidCon UK – but, in a unique twist, his iOS counterpart too! What did they think of it? Which platform is best? And did they have a fight about it? The results are in and the verdict is below…
UrbanThings Head of Platforms, David Else, discusses the challenges of managing internal .Net dependencies and how we’ve created a robust and performant solution to address this.
Many of our platforms here at UrbanThings are built using Microsoft .Net, project dependencies are managed through the use of NuGet packages, and we manage both internal and external packages in the same way. Re-usable, shared components are built into NuGet packages and uploaded to our internal NuGet server, which allows us to easily manage project dependencies, and limit the impact of changes to library code.
One of the major drawbacks to this process occurs when developing locally: when changes need to be made to the shared libraries a developer would need to make their modifications, manually build the libraries, package them, and copy them up to the NuGet server. If further modifications need to be made, this process has to be repeated. This can stifle a developer’s productivity, since they end up spending a lot of time building and packaging libraries instead of writing code.
To solve this problem, we have automated our build processes so that libraries are automatically built, packaged and uploaded to the NuGet server as soon as changes are committed. No more manual updates!
Jenkins is our continuous integration server of choice, mainly because it is very extensible through plugins, and has good coverage of multiple platforms, including .Net, Android and iOS. Using the Multi-Branch Pipeline plugin, Jenkins automatically picks up new branches as they are created within our git repositories, and automatically builds the projects when code is pushed.
The build process goes through a number of steps:
- NuGet packages are restored to ensure we have all of the relevant dependencies
- The projects are built
- Unit tests are run and the results collected
- Libraries are packaged
- Results are published
The packages are then published to the NuGet server where we have a special feed for development and pre-release packages, plus a production feed which only includes released packages. Any non-NuGet package results are uploaded to Amazon S3, where they are made available for deployment to development, test and production environments. We are also notified via Slack notifications of build completions and failures, so we can quickly and easily react to any issues during the build process.
It now only takes seconds to have code updates included in a library and made available on the NuGet server, and in order to avoid clashing with other developers’ work, the packages are versioned based on the git branch. As well as making our development more productive, this process also encourages developers to use appropriate git-flow feature branches for their work, and encourages them to check in more often.
I joined Urban Things in June to head up the Android development team, after eight years in mobile development at a cloud music provider. Prior to this, I spent fifteen years working in game development, dating back to the very first Java enabled mobile phones and various game consoles, mostly focussing on Nintendo handhelds. So it’s safe to say that the cornerstone of my career is mobile devices!
Some of the initial tasks I have been working on: a reorganisation of the code base to better support our growing suite of apps, and the production of a more modern and open source SDK to allow third parties to build against our platform.
I’m currently putting the finishing touches on a new flavour of our app which has a host of new features that we’ll be rolling out over the next couple of months. Beyond that, the future holds lots of interesting projects to get my teeth into, including a full visual redesign of our apps and a significant codebase overhaul to modernise the Android architecture. Part of this overhaul will be based around RetroFit, OkHttp, RxJava, as well as other well known libraries, and (hopefully!) a smattering of Kotlin.
Watch this space for some technical blog posts as we work through this.
I’ve joined a small but perfectly formed company at an exciting time, and look forward to seeing how we grow and progress while building new features that make it easier for the end user to get around – whether they are in New York, London or Sydney.
Ian’s 5 Favourite Things:
• My family, wife Gemma, daughter Amelie who is three going on thirteen, and dog Indy – named after the whip and fedora toting hero of course!
• Coffee, coffee, and more coffee
• Food, I love eating (and cooking) different food and cuisines
• Cycle racing, this helps offset the eating…
• Technology, making phones, devices, servers and data all work together never gets boring!
• Off by one errors
When creating assets for mobile apps, it can be a pain – and a time drain – to manually resize multiple images to their relevant screen density. For example: 1x, 2x, 3x in iOS or MDPI, HDPI, XHDPI etc in Android.
With a little experimentation, I created an AppleScript that allows you to re-size and copy an image into various asset-specific subfolders. And with Automator magic, this can make your resizing process as simple as right-clicking on a file.
5 Steps to Heaven
- Copy the contents of this AppleScript file to the Clipboard.
- Open the Automator app in Mac OS, then create a new workflow of type ‘Service’.
- Set the input to your Service with ‘files or folders’ and ‘Finder’ in the dropdowns.
- Drag the ‘Run Applescript’ action into your workflow and then paste the contents of the AppleScript file into it.
- Save the Service using a descriptive name such as ‘Create Mobile Assets in Folders’.
Using the AppleScript file
- Save your image file somewhere at x4 of full size, i.e. XXXHDPI.
- Right click on the image file in ‘Finder’ and choose the shiny new option that should now be in the drop-down menu.
- Subfolders will be created for each size ratio and the image will be copied into them.
As mentioned above, the script assumes that your image is already x4 of display size, i.e. XXXHDPI in Android terminology. If you need to change this, or customise the sizes and ratios, just edit the first two lines of the script accordingly.
I hope you find the workflow useful as it can save many hours of fiddling around!
Here at UrbanThings, we use Confluence to improve collaboration within the team. Confluence is great for linking JIRAs to collaborative spaces and for tracking the team’s activities between projects.
But… it turns out that it’s also useful for the far more important task of sharing reviews of restaurants with each other. A development we can entirely blame on the UberEats money bomb launch, and the ever-so-slightly possibly-connected Just Eat scratch card voucher giveaway outside Old Street station.
And in case the boss is reading this; there is an obvious business benefit to this valuable work: satisfying the team’s hunger will make us work harder! 😉
Now if only there was a free add-on to allow everyone to give marks out of ten…
• K10, Japanese – “Excellent chicken gyoza”
• Hungry Donkey, Greek – “fluffy tasty bread”
• Homeslice, Pizza – “crispy and light dough base”
• The Falafel Queen, Falafel – “falafel-tastic” (just in case you weren’t sure it was a falafel place…)
• Hop, Vietnamese – “Tasty aromatic beef hotbox”
Coming from a strong iOS background at both small and large companies, I was really excited about the idea of bringing my experience to a start-up like UrbanThings.
Since joining in April I’ve been mapping out a course to update the UrbanThings codebase so we can provide a more solid and flexible foundation for the company’s future aspirations. That’s the short version, continue reading for the longer. 🙂
The first significant piece of this process was to overhaul the publicly available open source iOS SDK within the UrbanThings Transport API. The result is a simple to use modern SDK that also provides a great deal of flexibility for those who want to do more with the code – you can see more on Github.
Version 2.0 of the SDK also coincided with Bristol API Hackathon 2, I played a key role at this event and introduced a number of developers to the SDK, the day also generated some great ideas from the community and our winners for the day blogged about their experience.
Since then, I’ve been refactoring the codebase into a set of frameworks, introducing abstraction through protocols, and configuration through dependency injection. We have set up a continuous integration server, increased the code coverage of unit testing, and are bringing in a formal QA process that includes automation testing. We are also moving the iOS codebase to Swift where possible.
All of these changes will improve UrbanThings’ speed and ability to introduce new features and designs to our customers, and will allow us to have more confidence in the reliability of these updates. We have some great ideas in the pipeline and I’m really looking forward to launching these – watch this space!
It has been a bit of a whirlwind these last two months, but I’m really happy in my new role and am part of a talented team with great ideas for bringing transport information to you through mobile technology… one app at a time!
Mark’s Top 5 Ways to Unwind
• Running around the country lanes of Berkshire
• Spending time with my wife, our new baby, plus keeping an eye on the grown up children
• Teaching and practising karate
• Playing guitar
• Travelling to other countries (see above for Al-Khazneh from Indiana Jones and the Last Crusade)
As UrbanThings expands, so does the number of great suggestions for our mobile apps. These come from end-users, beta testers and our own internal team – anything from great ideas for UI tweaks to full-scale feature additions. We love all this feedback and we don’t want to lose it.
Integrating feature and enhancement requests into our workflow posed an interesting challenge. We use JIRA to track our software development; filing new suggestions directly into a platform team’s JIRA seemed a little intrusive, but documenting them entirely outside of JIRA seemed disconnected from the process. We knocked around some ideas to help generate a process that would track these valuable ideas and PAT came to our rescue.
PAT is our newest JIRA Project, or to give him his fuller title, ‘Potential App Tasks’. Functionally, PAT exists as a ‘clearing house’ for ideas and suggestions that come from our end-users and development team.
The full lifecycle for New Features and Enhancements is now, in broad terms:
- End-user support staff and developers generate enhancement and new feature tasks, and file these as issues within PAT. We use components to track the relevance of each issue to one or more platforms. We also integrate JIRA with ZenDesk to track any related end-user feature requests.
- The Product Manager periodically prioritises and approves key tasks. Approved enhancements are then filed as new issues in one (or both) platform-specific JIRAs, and linked back to their PAT ‘parent’ for tracking purposes.
- Development teams then integrate the enhancements into their regular sprint planning.
- The enhancements are completed and the apps are updated. At this point, any linked end-user tickets in PAT can be actioned and the users informed that their super-amazing suggestion has gone live.
And, of course, nothing says PAT quite like our choice of Project Avatar.