![]() |
![]() |
|||||||||
|
||||||||||
![]() |
![]() |
|||||||||
|
||||||||||
![]() |
![]() |
![]() |
#31 | |||
14th
20KPINAL
Join Date: Jul 2001
Posts: 39,366
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Quote:
What challenges are there with the conversion type approach. |
|||
![]() |
__________________
Seriously not taking motorsport too seriously. ![]() |
![]() |
#32 | |
Veteran
Join Date: Mar 2015
Posts: 10,483
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Hybrid applications tend to have a single codebase, that either spits out an Android and iOS app at the end, or provides a single app that works on both. So you really only have one codebase to look after, which means it'll probably be quicker to develop the app, and you're only maintaining one codebase after it.
The downside of the hybrid applications is they tend to be slower performing than native applications, since you're not using the products exactly the way Google and Apple intended. You also tend to not get the latest and greatest features - so AR for example. Granted, neither of those are really an issue for TRL as it's a very lightweight app, and I won't be using hardcore new features. Although you're only maintaining one codebase, it will probably be harder to maintain - as Android and iOS change, it's going to break your third party hybrid app. Whilst if it's written in native Swift (iOS) and Kotlin (Android), it will most likely be backwards compatible for many years. For me, it was because I'd done things backwards. I never intended on building an Android app (I'm an iOS developer really), but because I had so many requests I couldn't ignore it. The iOS app was already released, so I had the choice of do a hybrid app for Android (and either keep or bin the iOS app), or do Android 'properly' with Kotlin, so it was done properly - with the help of a much more experienced developer than me. Im hoping it being built in Kotlin means I won't have to do any major re-writes of the Android version any time soon! On a kinda related techy note, it's been interesting doing development on both platforms and seeing the pros and cons of both. Apple Pros: - The tools are incredible. They literally do just work. Download Xcode and just start - The framework I used (SwiftUI) is super slick and simple to use. - OS support is amazing. My app works all the way down to the old iPhone 6S Apple Cons: - Expensive. £100 a year just to be a developer - Some frameworks (StoreKit especially) need some serious updates - Not a very flexible app store system. You don't have many options available to you. Android Pros: - App submission is faster. The submission and approval process is almost immediate, unlike several days for Apple - Cheaper. £30 a year to be a developer - The Play Store submission has so many options it's unreal. A/B testing, incredible analytics, etc Android Cons: - Android Studio barely works, and the simulator doesn't. You HAVE to have a physical device to work on - The Play Store has lots of options, but some don't work, and the layout is a mess - OS support is terrible. There are people with 2 year old devices that can't run my app because they run Android 9 It's funny. The systems are what you'd expect from the 2 sides, even as a developer. Apple is more expensive, but it works beautifully - but it forces you down certain routes with how you build things. Android is scruffy, but god damn the amount of options you have available to you is amazing - you have complete freedom. Overall I prefer the Apple system, but it's obvious why many would prefer Android. |
|
![]() |
![]() |
![]() |
#33 | |
Veteran
Join Date: Mar 2015
Posts: 10,483
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
I've released update 1.43 for iOS.
- Added support for iPad widgets - Added a larger widget for iPhone 12/13 Pro Max screen sizes - Added ability to display race distances (300km races for SuperGT for example) - Added ability to filter races based on the following things -- Series type (single seater, touring car etc) -- Session type (race, qualifying) -- Session date (see races between set dates) |
|
![]() |
![]() |
![]() |
#34 | ||
14th
20KPINAL
Join Date: Jul 2001
Posts: 39,366
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
I missed the comparison of Apple android when you posted it a few months ago. Interesting and funny how it is pretty much what you’d have guessed.
![]() |
||
![]() |
__________________
Seriously not taking motorsport too seriously. ![]() |
![]() |
#35 | |
Veteran
Join Date: Mar 2015
Posts: 10,483
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Almost a year into this app, time for another update.
I've added the following series for 2022: - Goodwood (FoS and revival) - Isle of Man TT - Indy 500 Qualifying - Le Mans Weekend (Practice, Qualifying and Test Day) - GT Open - Extreme E Some of these may not display until closer to the time. (Some currently support events may not be displaying as there is no confirmed data yet - GTWC Australia as an example) Currently working on an App Store submission with the following features - support for 'All Day' events like Goodwood - better notification text for 'All Day' events - fixed a bug where the filter applied to the Calendars view - moved widgets out of beta |
|
![]() |
![]() |
![]() |
Thread Tools | |
Display Modes | |
|
|
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
theracingline RC.net backup back | the.cosmic.pope | My Track Designs | 3 | 1 Apr 2009 19:33 |
AOL.COM e-mail users / No Notifications / No Registration e-mails. | MagnetON | Announcements and Feedback | 3 | 26 Sep 2006 09:57 |
e-mail notifications | MagnetON | Announcements and Feedback | 3 | 4 May 2005 22:16 |