Some basics of the framework
- Application.Mainform is the one and only „MainWindow“ which is visible throughout the lifecycle of an app
- „MainWindow“ is used as a container for any other „view“ of the app
- a view is a layout carried by hidden form which is created / disposed as needed
- use of TForm as container for easy definition of layouts per device in IDE
- a view is displayed by changing parent to „MainWindow“
- going down in view hierarchy a view is put on a „history“ stack
- going up in hierarchy current view is disposed and view on top of „history“ stack is displayed
- „Back“ button is checking for special handling by a view before stack
- view templates: splash, login, about, settings, main, list, image etc
- on startup all necessary views are registered with an alias, formclass, etc
work in progress
- persistent settings
- application events
- SQLite integration
- multi language
After all this trouble – minimum 4 weeks lost – I replaced THTTPClient with Indy TidHTTP. Not too much work and the basics worked within an hour or two.
One new problem introduced by Indy was that TidMultiPartFormData did not work as expected. For a quick solution wrote data in a TStringStream and sent instead.
SideEffect: The app did not work when compiled in 10.1 Berlin. Now it does !
Have an app which is working 100% on Android devices (no REST backend):
querying JSON data, fetching/uploading logos and images.
But on iOS we ran into big troubles:
- chunk data sent as TStringStream led to exceptions on server like this
„Exception EConvertError: Invalid URL-encoded char (%Yπ) at position xx“
(TMemoryStream did not help, but base64 encoding did)
Android doesn’t but iOS does URL-encoding with chunk data
- any HTTP parameter is logged on server like this
name=““Session“““ with multiple double quotes
- changing to a TMemoryStream result looks like this
- but same example on Android
It is quite difficult to debug and a time consuming process, but I will try.
Still working on problems with chunked file upload. Really crazy how much time is wasted with problems by different handling of HTTP in components and/or platforms.
I think that there still are quite a few bugs in FireMonkey internal but making demos to reproduce problems would need an huge amount of time (weeks or even months) I am not willing to invest as everyone I need to earn money for living.
But I will gather all infos and post them here.