Over the past few years, I have been helping others with writing their mobile apps, or some parts of their apps where they have called on my expertise to do the implementation. I am happy to announce that I have published a mobile app that I can truly call my own: Memorizor.
I actually started Memorizor just under 3 years ago, however because it was a personal project it received less attention than it otherwise should have. After releasing Kastri a few months ago and starting to seek sponsorship for the project, I felt it was time to put together a showcase of some of the current features of Kastri as well as giving a preview of what is in the works, so I chose to resurrect Memorizor because it was the perfect candidate.
What is, and isn’t, in Memorizor
As above, Memorizor makes use of some of the current features of Kastri, and some that are to be released in the future. Of the current features, It includes a number of units from the API and Core folders, as well as the Speech Recognition feature. Some of the “to be released” features include:
- Implementation of the native AlertView on iOS. The released feature will contain support that mimics the AlertView, for other platforms.
- Native image controls
- Native camera support
- Image zoom/pan
The rest is all “out of the box” Delphi. Some of the notable parts of Delphi that are used:
- Local Notifications
- ListView with dynamic appearance
- FireDAC (just TFDMemTable)
As any seasoned Delphi developer (or perhaps any developer, for that matter), some things do not go to plan. There were a number of issues that I needed to work around, and have decided to list them here:
- Geocoding can cause a crash if there are no results (https://quality.embarcadero.com/browse/RSP-30483)
- Location sensor does not fire location change more than once (https://quality.embarcadero.com/browse/RSP-29859)
- Virtual keyboard does not change type when changing focus between edits with different keyboard types (https://quality.embarcadero.com/browse/RSP-30045)
- Local notification event does not fire if application is in the foreground (Yet to be reported)
- There is no way to detect if the user has tapped “Cancel” for a combobox on iOS (Yet to be reported)
The ComboBox challenge
The last one in the list above deserves an expanded explanation: some developers suggest using a workaround where the ItemIndex is stored before the combo “drops down”, and when the combo “closes up”, check the two values, which works for most situations, but not for mine. In Memorizor, on the Reminder screen (where the “remind mode” can be changed), if the user taps the combo that is “blank”, the first item in the combo is selected (thus no longer “blank”) and the picker appears. The user might then change the value to something else, however they may decide to tap Cancel anyway. This means the value before and after the selection are different, however the user tapped Cancel, so the value should not be applied. Long story short, I defined a new message class: TComboBoxCancelMessage, and patched FMX.Pickers.iOS.pas to send an instance of that message if the user taps Cancel.
Requesting permissions for access to device resources has become an everyday thing now, however it can become annoying when an app confronts you with a barrage of permissions requests. In Memorizor, I have paid strict attention to delaying requests for permission until they are absolutely needed.
When implementing Local Notifications, I noticed something a bit odd – I was delaying creation of TNotificationCenter until it was actually needed, however it did not seem to matter: the permissions request would appear always as soon as the app started. The answer is that in FMX.Platform.iOS, in the TApplicationDelegate.applicationDidFinishLaunchingWithOptions method the code checks for whether the app has FMLocalNotificationPermission set to true in the Project Options, and calls TiOSHelper.SharedApplication.registerUserNotificationSettings which prompts the user to grant permissions – that’s why it happens at startup. The solution was to set FMLocalNotificationPermission to false, and do that part myself in my own code, when it actually needs permission.
For things like access to camera, speech recognition, and locations, these were relatively easy to defer the request until absolutely needed, however you should still be mindful about it.
As I have been writing this, I realise that there were actually quite a number of challenges to overcome. Most had nothing to do with issues in Delphi itself; just regular scenarios where more effort was needed than first realised. I’ll store them away for now, for appearance in future articles.
Now that the iOS version has been published, I’m working on completing the Android version, which brings its own set of challenges. I plan to have that available by mid next month.
I’d like to thank my current sponsors, those who used the Paypal tip jar (in the top right of this page), those who tested Memorizor for me, and of course to Embarcadero for their amazing development tool Delphi, all for their help in making this possible.
This has been a long road, however I have laid the foundations with Memorizor which should make it easier for me to do add new features, and to be able to build the next app. It has also boosted my own appreciation of the work I’ve put into Kastri. I hope that what can be seen in Memorizor encourages you to take another look at Kastri and consider becoming a sponsor to help continue its enhancements and new features.