Welcome! This episode is all about mobile apps, featuring our senior software engineer Ravinder Bhandari! We look at some of the specific strategies we used to create apps for IoT smart devices, featuring Koodaideri Innovation and Technology's HydraTune SafeAdjust, SRAM ShockWiz and AXS Mobile and more.
Hosted by engineer & managing director Ayrton Sue, The Engineering Triangle is all about IoT product development and manufacturing across key engineering disciplines - mechanical, electronics, firmware, web & app software, and UI/UX. How do you make the best digital solutions, as fast as possible, at the right cost?
You can stream it on Spotify, YouTube, and all your favourite podcast apps of choice!
For those who would prefer to read rather than listen, here is a transcript of our conversation.
Ayrton: I’m here with Ravinder Bhandari, our senior software engineer. Ravinder has 11 years experience developing mobile applications for Android and iOS platforms. Thanks for coming on!A bit of background about Ravinder. He’s very experienced in mobile application, having progressed through being a senior developer up into management working for one of India's largest app developers for Android, whose applications had millions of users.
Ravinder’s family was here in Australia. I put an advert up on Seek, and Ravinder decided to come and join the team here at Element. He brings a wealth of experience that we’re using to go and do more cool stuff.
What makes an app great?
Ayrton: To start off with, what are your favourite mobile apps? What makes an app great?
Ravinder: I would say the simplicity of an application is what makes it a best app. Simplicity in terms of what you want to achieve with it. It's by providing the best user experience in achieving the purpose that the app is built to serve.
Airbnb is a great app. It is available worldwide, and it's available in all different geographical areas with all different cultural backgrounds. And the way it handles those localisations is done in such a subtle way that it's there in the app, but you would never notice it separately. That's what makes it a great app for any user who's just interacting with the app for the first time.
It serves a purpose straightaway, doesn't get you through a lot of stuff that you're not supposed to know or think about.
Ayrton: Sounds like a lot of work to get to that point!
I use the Reddit mobile app a lot, because of tech communities on there. It's gotten way better over the years. It used to be just a web page, but now it's a proper app. Other social media applications seem to throw up junk that you don't really want to look at. I don't know why I'm looking at Nissen Patrols and cray fishing, which is an interest of mine, but I don't want to see it when I'm signed up to all the tech stuff that I'm really interested in. But when I go to Reddit, it just seems to work.
Ravinder: Which always comes down to the user experience. And see, for you, the key point here is that you are more interested in the data that’s sourced. Now how that data is getting served, it also matters that it's always in the background. You would never notice if the data’s served properly. But if there's ever an issue with the user experience, you'll start noticing it. And the reason why you don't focus on it is because Reddit does it seamlessly.
Ayrton: Yeah, they profiled me pretty well, they know what I like!On the other side, what are some of the worst apps that you've seen? You would have seen a few of them, right?
Ravinder: So when you are going from point A to point B, the journey matters a lot. All of that journey is what makes an app best suited for the user. That's what's missing.
Ayrton: Banking apps make me nervous. You know what I mean? Some of them feel like it's much easier to find what you're trying to do and make a payment. One of them, which is my personal bank, just feels clunky in the way that you're trying to set it up. You've got to flick backwards and forwards. It doesn't seem to give you the information you need to be able to make that payment easily to that person that you're paying back 50 bucks or whatever.
Ravinder: I've noticed that. I think they're more concerned about the security aspects of it rather than the user experience. Having both is always good.
Developing mobile applications quickly
Ayrton: Considering the engineering triangle, speed is a major part of any engineering.
Ravinder: We are talking about building native apps, which always require you to have dedicated resources that work on Android and iOS applications separately.
There are different ways of making an app. You can make a hybrid app where you would have a common code base that would run on different platforms, such as React Native or Flutter, that can be used to build applications for Android and iOS both.
But going native is the way to write a dedicated separate code for mobile applications. You have a separate code base for Android, a separate code base for iOS. And so on for Windows Mobile.The thing about a native application is, since you have to build a separate code base and you need dedicated resources, it takes some time.
Now how do you optimise that? How do you make sure that you are able to use some of the logical aspects that you're implementing in different languages and then reuse it for different platforms? The best way forward we see and implement here at Element is to build applications using generic libraries that can be ported into different platforms. We use Kotlin and multiplatform languages to build our native libraries for Android and iOS, import it into the specific code base, and then have a single logical layer.
Ayrton: So basically creating reusable code that can be used in multiple places through the app?
Ravinder: Yes. And also being able to port that same code to different platforms. That's one way to make native apps quicker.
Ayrton: We created our first application years and years ago for tyre pressure sensors in iOS, Objective-C, back in the day.Then the first production application was ShockWiz, and we did that in Cordova, which is a JavaScript based language that can be applied to iOS and Android.Because we were interfacing with Bluetooth, we still had to write specific code modules that would interface with the iOS' Bluetooth system to go out to the ShockWiz device or the Android.
We developed the ShockWiz app quickly, but it came with so many compromises. And the big compromise was performance.
Ravinder: Yes, that's always the thing with the hybrid applications. When you want to interact with the hardware, the best performance that you can get is always through the native applications.
Even if you are building a hybrid app, let's say using React Native, you would use some plugins available for interaction with the hardware. But they are always less performant in comparison to the native applications. And if you have to write a specific piece of code that works especially for Android or iOS, you still have to do that separately. So what's the point of having a common code base if you are still writing the specific use cases?
Ayrton: In regards to code, most recently we've been using new coding languages that are more closely aligned, such as Swift for iOS and Kotlin Jetpack Compose for Android. And the structures of those code bases are more closely aligned so that the modules within the code are on par with each other. So that was something we learned about four or five years ago that has gone to production in a few apps that we developed.We have had certain engineers who can do both iOS and Android natively across both coding languages. But people still have their preference, right? Like you’re an Android guy.
Integration with Figma
Ayrton: I would say the other key to developing native apps quickly would be the UI aspect, right? Having engineers do any sort of UI work or having to interpret specifications to then create a UI is probably a waste of their time. We are using Figma these days to basically do all of our mock ups. And the information can basically be pulled out of that pixel-perfect Figma file directly into Jetpack Compose or Swift UI Elements. Previously we used Adobe XD, which is very, very similar to what Figma is now.
When you work with Kathryn and Nicole on Figma and UI based tasks, what’s the workflow?
Ravinder: These designs give us a good understanding of what the client envisions the end product, and gives us an idea of the user journey. What components we need, and how they should be designed. The text sizes, the font styling, the colouring. And we can design all the theme related components within that application.
Ayrton: All those things are part of your code base, right?
Ravinder: Yes. So how do we reuse those elements? We designed a library called Element UI with over 70 generic components we need for any application. We've designed this library so that whenever you want to create a new design theme for a new client or application, you can just input those theme configurations, like what font stylings for headings, the body, colouring, etc. Once you do that, your components are already designed and you've saved a lot of time in building it from scratch. You just have to work on the page design, that's it.
Ayrton: So the process usually is, the client comes to us with some requirements and usually some hand sketches or mockups. We then go into Figma, detail exactly the screens, the exact workflow, every single screen, every single tap, to a degree. Depending on the level of complexity the customer wants. But usually we emulate every single screen.And what we are now doing is reusing those Figma UI elements. Those components visually in Figma are already aligned with your code base.
So for us to be able to do fast and good and low cost, we had to have done a ****load of work in the background to create those libraries which then allow us to turn around app development really quickly and consistently.
And the engineers don't have to worry about what this thing looks like. They literally take the pixel perfect position of those things, apply them into the code. Apps are more effort than a lot of people think. Especially apps that are performant!
Ravinder: Everyone thinks they can build an app. But when you actually start making one and you push it out in the market, you would notice all the different screen sizes you want to support. There are like a million different types of Android phones out there. And once you start thinking about it, then you'll actually see, man, this is not as easy as I thought!
The Challenges of Apps for IoT Smart Devices
Ayrton: Bluetooth is hard. It seems easy, interfacing with a microcontroller that could cost you three bucks. But you only get a certain amount of data that you can send.
Years ago when we made ShockWiz, you get something like, I think it's 20 characteristics. And those are read or write or read/write. From the phone you can read them, you can write to them, or you can have bidirectional communication. You can even get notified on those things. So when we first made ShockWiz we had things like pressure, statistics, things like that. Each one of them had a different characteristic. And we used up all of those 20 characteristics pretty quickly.Once we wanted to add more critical features to the project, we ran out of characteristics. So we had to end up creating a pretty complex sort of bidirectional communication system using two characteristics.
And we ended up over time being able to stream hundreds of data points a second coming from the pressure sensor and the accelerometers, raw data, and then use it in algorithm generation or algorithm improvement.
That process was really hard, especially when you're interfacing with a device that has its own firmware that may have its own delays or bugs. On both sides of the firmware and the Bluetooth device, you may be being affected by a part of the code base you're not seeing.
Collaboration between the device, the person coding the device, and the person creating the app is super important. It has to be hard, unless the Bluetooth product that you're working with is very mature and has a good code base and you're only doing the app.
And the other part about IoT is, you're always involving data. Data can be slow, it can be fast. Whatever it is, you've still got to be able to transfer that information. And you've got to be able to do some level of control. So the user has to have some sort of input that exchanges information, or the user takes information and then does some sort of input to change the system. There are always a lot of inputs and outputs.
You've done a lot of IoT stuff now, especially safety critical IoT device systems here at Element. What are some of the challenges?
Ravinder: It might seem easy that you just call a function to connect to the Bluetooth and you're connected. But then there are a lot of things that you have to take care of in the background.
And what if someone turned the Bluetooth off? What if it's already off? What if someone denied the permission? Once you’re connected to the Bluetooth, there are 100 other things that you have to take care of. You just cannot start sending data. You have to notify the device, and then the device has to notify back to you.
And you’re limited to the amount of data you can send in each packet. So even if you're working with Bluetooth 5, you cannot send more than 512 bytes. That's including the MDU itself. All your Bluetooth communications or interactions would definitely be a few kilobytes or maybe megabytes.
So you have to chunk your requests, send packets of data one at a time. Queue up all the requests, then make sure that they are able to process all the requests asynchronously and then combine the response back together and then show it on the UI.
There are a lot of things that must happen in the background. And we do it in a way that we can use for multiple projects by creating a generic library, making sure we don't do the same thing again and again for other clients. So that's what we do and we have done to create good quality apps.
Ayrton: And it's improving all the time. Ravinder is the best person for taking away some specifications that we talked about and wrote on the whiteboard, and coming back about 4 hours later and going, here’s all these different edge cases that we didn't think about.
I haven't done much coding myself. I've done a lot of Python coding, scripting and things like that, but not software development. Would I be right in saying that the majority of the work would be around handling the edge cases?
Ravinder: Yes, that's so true. I mean, covering the happy cases is very easy. Like when you're adding two numbers, anyone can do it.
But when you think about the edge cases, like someone's trying to add a number to a string. Or someone's trying to divide a number by zero. These are the edge cases.But now think about edge case handling from a Bluetooth perspective. There'll be endless scenarios and situations that you can get into.
Ayrton: Apps are hard. Software is hard! My preference is mechanical and electronics.
Native vs Crossplatform
Ayrton: For IoT applications, is it better to build apps natively or use cross-platform tools?
Ravinder: Everyone wants their product to be built faster so that they can build it in low cost. Hybrid applications can help you do that. But then it depends what features you need.
If you need really good hardware interaction and performance is the key for your application, then going for hybrid application development is definitely not the right direction. That's where native applications come into the picture.
You would still have to write a specific piece of interaction with the hardware in the native, even if you're building a hybrid app using React Native. If you end up doing that, then why not just build the application in native and get the best performance?
Of course, it's going to take a little extra time. And to optimize on cost, that's why we build generic libraries so we can deliver faster.
Ayrton: Have the cross-platform or hybrid app tools gotten better?
Ravinder: You'll find plenty of plugins out there in the market because there's a very mature developer community available to build on React Native or build on Flutter. But the thing is, those plugins are always having some sort of bugs or not be as performant when it comes to interaction with the hardware.
Ayrton: You’re at the mercy of someone else maintaining that piece, right? That’s something we've come across a lot, especially in IoT development. Mainly web applications that I've sort of done. Utilizing someone else's library is great - when that library is maintained. But not, someone's going to fork it. It has to be a well maintained library. Recently we had to rebuild the ShockWiz app. Some of the libraries that we were using were out of date and things like that. It was a harder project to refresh the Cordova app to then support the new Android operating systems, than it was to build a whole new Android app from scratch.I could just see from the interactions that you guys had that updating those modules was going to be way harder than rebuilding.
Ravinder: That's right. And the performance difference that we got, it was quite visible.
Developing SRAM ShockWiz and AXS Mobile
Ayrton: On that note, we've done some app development work for SRAM, who produce high tech bicycle components. Namely the ShockWiz and AXS mobile apps. We started working with SRAM in 2015 on ShockWiz, which we took all the way through production.
We were doing vehicle tracking projects here in Western Australia with a couple of our own IoT devices running around the mine site. And from that sort of vehicle tracking, we got the opportunity to work with SRAM on their AXS system.Initially AXS was basically to visualise ShockWiz events on a map. The events that we were creating for vehicle tracking were bumps, corrugations, harsh turning events, harsh braking events. So we had already visualised those kind of events.From there that progressed to, okay, if we can do that for ShockWiz, that's great.
But SRAM’s got all these other Bluetooth devices, and more and more of them were coming on line. And we ended up making the AXS Web application. That was running in parallel with the AXS Mobile application, a cross-platform app in the early days. We got the opportunity to do a proof of concept for an all-native application. And that was with the new toolchain that came in, which was Swift UI and Kotlin with Jetpack Compose.
But you've come into it later in the piece at Element. You've been here a couple of years. What have you learned about the SRAM apps that we've developed?
Ravinder: This is like a totally different experience, I would say. Because when you're working at scale, you get to focus on a lot of things that you would not think about normally. Especially if your product is being used by millions of people.There are a lot of use cases or edge cases that you will not be able to identify when you're doing all sort of testing and development. So that's one thing which we definitely have to focus on.
Ayrton: When we first released the ShockWiz app, we had a number of different supported Android versions. And then we got the analytics back from the app to Firebase, and we could see when things were crashing. We looked at the bell curve of the distribution of people with different operating systems, and there were some people who were using really old, I think it was like Android 4.
There's a certain amount of effort to keep maintaining this app to that level. If we were to upgrade it a couple of levels, we might lose 20 people. But the other 200,000 people will benefit. You have to make hard decisions at some point and say, well, these people are actually using too old of a device.
Ravinder: Back then the Android system itself was evolving. And then if you couldn't support a very old version of the operating system, it's mainly because you're still using some older functions. But if you drop a few of those versions which are very rarely used, then you can get the benefits of all the new updates.
Ayrton: The other thing that comes to mind is UI components. When developing mobile applications, we’ll use an iPhone 4 or the iPhone SE size now, that's your smallest phone size, through to your larger sizes.
Then you might go up to a tablet. You’ve got the small sort of 10 inch tablets all the way through to like a 14 inch as well.
When we were designing the ShockWiz early on, I remember we went and bought Android phones from Walmart, which were like 50 bucks. And then you have your high end Samsung ones. All different sizes. And we physically tested all of them. We put the app onto all those things and you'd say, okay, where are all the UI components? Is anything squishing up? That was always the hardest part, you would design for your primary phone, and everything would look beautiful. But when we went to the smaller or the bigger size, things got strung out.
And I remember the guys being challenged to create the code in such a way that everything fit and scaled correctly without having to make a specific code base for each particular screen size.
Android's even worse, right?
Ravinder: Yeah. I mean even if the screen size is the same, there could be a different resolution. So we have to take care of the density pixel that the screen resolution uses. Of course Android has certain ways of doing it, but it's still not as easy as it looks. It's challenging.
Ayrton: SRAM is a great client to work with. They've given us some crazy freedom to do things, and it's been fantastically beneficial for them as well. That system we created, which was made up of generic reusable components, is actually part of their AXS Mobile app now. We did all the proof of concept for that and initially did all of the system settings, and we help them maintain it every now and then.
Ravinder: And they've always trusted us with our calls. Like when we suggest certain things, they always go for it. And then they understand, okay, we know the system better.
Ayrton: A longstanding relationship with people who understand tech makes it easy to have those conversations. But you don't learn it until you do it. It's a hard place to play.
Koodaideri’s HydraTune SafeAdjust
Ayrton: We designed Koodaideri’s HydraTune system for hydraulics technician safety. Part of that system was a native tablet app, SafeAdjust, to perform remote adjustments out in rugged conditions.
That was your first big Element Engineering IoT app project, a critical one as well because if that device malfunctions, it could be as dangerous as previously when people were adjusting these high-pressure hydraulic systems by hand.The system had to be safety critical. And the communications from the device and the firmware, between the tablet and the firmware on the device, are critical in making those adjustments. You were integral in making all that happen. How did you go about it?
Ravinder: Thanks for saying that. I came to you with the idea to build this library that we can use for Bluetooth interactions. And you totally supported it. It has gone into a good direction for us.
Ayrton: It's the only way we can do it fast and at low cost. We were going down that path anyway, and we had to spend the time and the money to do that internally It's something that we needed, an asset that we can provide to our customers.We implemented it for HydraTune and along the way you improved it. You put the HydraTune layers on top of it, which is what the customer pays for. And as we figured out what the limitations were, you went back and improved it in the background, right?
Ravinder: Yes, 100%. HydraTune became our first testing ground for the Element Sync Bluetooth interaction library. We wrote a custom layer for HydraTune that has HydraTune specific end points that the device interaction would need.
One of the pieces was having those generic libraries, and the second component was having a very good collaboration with the Firmware team. That really was necessary because it’s very hard to debug stuff if you are not having good collaboration to understand exactly where things are going wrong.
Ayrton You spent a lot of time with Sam working very closely. If you've got bugs and you don't know which side they’re on, you can go chasing down bugs in a code base that may not be there. It comes down again to decreasing cost and increasing speed. Yeah, you could solve it by doing some more code over here. But if it's easier to change the code on the other side that gives you the advantage, then why not do that? And that only comes with having an integrated team that works across those multi-disciplines. We do things the hard way here at Element because we really want to do the best we possibly can. And you can't do that without having the full control of the ecosystem.
SafeAdjust was a great one. They're out there now with devices in the field being actively tested in operation. No news is good news, which is great. It's doing its job and it's doing it really well. It's really hard conditions. Having good reliable Bluetooth communications from the cab of the truck all the way down to the device with a large antenna was challenging.We've got the ability to update the firmware for those devices. Any improvements that we create or learn over time will be rolled out to HydraTune as well, which is awesome.
Do you have a lot of tests or things like that that you use in creating the app to facilitate things or to expedite work?
Ravinder: Yes, we do test driven development to make sure that we have covered all the edge cases, especially when it comes to an app like SafeAdjust where the synchronisation or communication of the device is very critical. That's where we have added a lot of test cases. And especially testing for the interaction library itself, so we put those pieces in and made sure every interaction or communication with the device is happening seamlessly. And we have at added a lot of fail safes on top of it. We've tried to make sure that even if there's a package that get lost, how do we tackle that? So all those things we encountered while we were doing all the testing and writing those test cases. And that's how we got to that stage.
Ayrton And you've also got the devices on your desk, right? Like the dissected device. It doesn't have all the casings and stuff. But it's the circuit boards with all the antennas actually with a stepper motor doing its thing. You're actually interfacing with real devices when you're doing your testing.
Ravinder: Yeah, we’ve got a dedicated device in our system that's, like, dissected. And we can actually test with it to see if everything's working fine. And if just in case something is not working, we'll go to the Firmware team and talk to them about it. Okay, this has some issue. Maybe it's on our end.
That's the good thing about collaboration here, because we don't try to blame others. We always say, OK, it might be something wrong on my end. If I talk to Sam about it, he would say, oh maybe something's wrong in mine. But then we debug it together and we figure out what's wrong.
Ayrton: Yeah, that's the only way. The only way in IoT.
Cranio
Ayrton: We're currently working on our very own data logging and control system, Cranio, to make it cheaper and easier for everyone to develop their own IoT solutions. All that extra work that we've had to do in the background for our clients has just culminated in this Cranio ecosystem. The ecosystem is primarily a library of electronic subsystems that we know work. It’s firmware that is basically a control system, operating system, and drivers for each one of those electronics. And the communications with our own communication protocol to work between device to device, device to app, device to web, those sorts of things.
It's then a web application, so the web backend and frontend. And also your app ecosystem, those generic libraries you talked about before.
One big key to the whole system is that, early on, we made the decision that we would speak the same language. All the devices in the whole system would speak the same language. From device to device, from device to app, from device to back end.
So we're using Protobuf libraries, one of Google's code bases, for intra device communications, where it basically breaks it down into different endpoint descriptions and compresses it into the most compressed format we can send. That gives us the advantage of not having the data overhead and also the latency that comes with it.
It’s been really ****ing hard to be honest. You know, having different people coming in and having their opinion about using JSON and this and that.I think you're one of the first developers we've had on board where you've said, yep, this is the way forward as well. Everyone's on board with it and we're all going to speak the same language. But it has been a challenge, right?
Ravinder: Yeah, definitely. When you're building something in a generic way, you must think about 100 other things that might not matter at that point in time. But it will definitely be helpful when you want to scale your system.
Building things in a generic way is always hard, it's always difficult, it's always complex. But it will always serve more purpose than just one client or one app. That's why it's also cost effective.
Ayrton: The Cranio ecosystem we've got facilitates a couple of different things for us. First of all, it gives us some assets we can use in client jobs, which we're already using.
Secondly, it gives us a starting point for certain projects that wouldn't have the funding and time to be able to develop something completely from scratch.Those customers that do want to develop something completely from scratch, great. We're happy to facilitate that and do that for them, like the SRAMs of the world. But if we can get to a starting point immediately, use the Cranio system as a starting point, that's been really, really advantageous for us.
We've had to put in, I think, something like 17 man years of effort that we've accumulated in doing this across the whole ecosystem. But it allows us to help people a lot faster.
And thirdly, yes, we are trying to develop our own product line that's going to use all of this. And it will be a generic IoT data logging and control system that uses all of these best practices and principles that we are trying to implement with our clients.Worst case scenario, if that never works out, we've satisfied the other pieces. But in doing all of this and going more towards our own product line, it’s teaching us everything we need to know about doing it better.And it's starting to cover all of those generic use cases like you were talking about. There's many aspects to it. But those generic libraries and having systems that you can help maintain and improve seem to be the theme. Not only in software but in electronics as well.
When we use the same subsystem, every chip has a bug. When you use it once, you sort of figure out, OK that's the bug, I’m going to improve that. Then you use it as a library component for the next project. It might be for Wi-Fi, Bluetooth, cellular, certain microcontrollers for certain things. Like a high-speed microcontroller or a low-cost Bluetooth-only microcontroller. But you end up understanding and learning exactly what works for that piece of the puzzle. And then when you apply it in different situations, it has to be tailored or changed for some nuance.That sounds exactly the same as the code bases that you're doing.
Ravinder: Yes, that's exactly the same. I mean, you would want to improve your code base. You would want to make it even more mature, cover all the edge cases that you might have missed a few times back. But that's just one aspect. The other aspect is, keep on adding more or new functionalities, new features, to it as you identify them.
Like Bluetooth interaction is one of the key things we've covered, but we're also covering Wi-Fi interactions. We are also covering API interactions on the back end. So yeah, enhancing your existing code base and then also adding new functionalities on top, they both go hand in hand. That's how you mature your ecosystem.
Ayrton: It's the only way we can help people do things faster and more cost effectively.
Comments