Rollo62

#meetoo

TLDR; Thats probably a little outdated. I meant the official docwiki, which is showing all necessary steps. http://docwiki.embarcadero.com/RADStudio/Rio/en/IOS_Mobile_Application_Development Edit: Especially interesting for the mobile development is the platform status, regarding OS versions and simulators http://docwiki.embarcadero.com/PlatformStatus/en/Main_Page

You need a Mac or MacInCLoud, as said above, as well as an Apple developer account, etc. See the descriptions in the DocWiki, this is very good to start with. Because XCode needs to compile and sign the package, there is no other way (or maybe by Hackintosh, but I would not trust that this is reliable).

@Sherlock You typed a ms faster @limelect There should be also an option to get used phones for testing, at quite reasonable prices. iPhone 6S is a good one, still quite current.

Depends what you want to do, I would recommend to have at least >= iOS11, don't know what phone that is right now (maybe iPhone 5).

I would recommend to use a real device as well, because the simulators are normally much different, especially if you go deeper into the mobile functionality. Even if the latest simulators would be supported by Delphi. You shouldn't be too much suprised if your app is running well in a simulator but might crash in the real world. Maybe the simulator is still OK if you only do some very basic and standard controls and nothing else.

Have you checked Spring4D ?

Have you considered to call several EXE files in the umbrella app ? They seem not be related much yet, so that could be a way to be faster.

Wow, Ok you have a bigger task to do then. I am lucky not to need to keep on old Delphi, I try always move further to the latest Rx version. Anyway, your project sounds like a task for big GIT scenario with clever CI. Good luck.

Hi there, since Apple forces all apps to supports IPadOS13, and I know what issues iOS13 already has caused, I would like to know what other desasters might come soon. From this list, maybe some major changes are listed, maybe there are already experiences from using certain API's ? Generally I hope that the basic API's are more or less untouched, and that not too many side-requirements are needed, but as far as I know will Apple stop uploads for apps not supporting iPadOS13 from 04/2020 on. Are there already good or bad news on the horizon ?

I was hesitating much before I started using them, because of issues in the past. Now they work fine for me in FMX (I don't use them much in VCL still). But I use them to separate UI, and I still avoid to make frames "component-like", to introduce them in the components toolbar. IMHO this cause all the main problems I have seen in VCL, so no "drag-n-drop", but well defined creatin in Code, like you said. Then I got no problems at all. I also have a second set where I used TForms instead TFrames, but since TForms are more heavy I prefer to use TFrames now. Only TForms may have other advantages, like Styling support, but also the TFrames can do that, as long as the main form has this defined. So its very open, I think you can use what you like, even Andrea Magni's great TFrameStand contains now a TFormStand component.

Maybe sometimes I avoid copy-and-paste. Just checking the form and dfm/fmx code, and manually change from TForm to TFrame is more reliable. Of coarse you need some more settings then after, but with copy-and-paste you loose a lot of relations in the code. But if you like to keep TForm instead of TFrame, you could also keep that, and load a Form in the MainForm. The advantage is mainly to be able to check and reset project settings fastly, while the forms/frames act only as separate views. That is more and more imporant, since so many changes occurs in platforms and in every new release, so its better to start new release on a fresh .dproj base. The separation helps (at least me) to more simply de-couple and test the views separately, as well as to re-use them in other projects. Nowadays I even start simple tests in same way, so that I'M able, after successful test, just to copy my "view" into another project, so to be able to contol some sub-features, or I can easily replace one implementation with another. But that of coarse needs more changes than only the separation of the main form ...

Not sure if that will help you, but meanwhile I changed all my main forms into bare containers with one carrier layout, with no logic inside. The real views I load as TFrame or TForm into that container then. This way its much easier for me to manage several versions of .dproj, especially with different platforms and all their special requirements in the projects. That means creating a new, clean and empty project file now is simple now, and I just need to add one uses entry to point to the real main form in use.

Didn't you choose to install Java JDK during RadStudio WebInstaller ?

Just did Xcode 11.2.1 and SDK 13 upload to TestFlight yesterday, it all worked well. Maybe you have to check the toolchain settings under the XCode preferences, in the past there was the need to update this or to install newer toolchain versions. Probably there is still an old toolchain left from the last beta release, which was deprecated. Since I try to make clean updates with XCode as well, I never needed to to this in the last years.

Hi there, I've try to optimize my BLE codebase from time to time, and there was always an issue with disconnecting BLE devices on mobile. This is decribed in this article nicely, and give some more clues and insights probably. I used to completely destroy my TBluetoothLE object, to get at least a working disconnect, although this sometimes may hang for 10 sec. and needed 2-3 trials before it really was ready to re-connect a new device. This article above gives some more explanations to the issue where the root cause of the problem may lay. Again I tried to remove the TBluetoothLE.Free and several other harsh measures, but the disconnect issue strikes back of coarse. I've tried to disable and re-enable BluetoothLE, which looked very good at first sight, but then made problems again on different Android devices. Since my TBluetoothLE.Free code is quite "messy" and more ad-hoc, I wanted to clean up (like every year). Maybe someone has similar issues, and found probably other solutions to the issue ? Would be great if we could share our experiences here. BTW: This issue also concerns iOS of coarse, but I think the issue with Android is harder at the moment.

Yes, probably thats adding issues on top. But I'm afraid this is a more deep issue in Android (as well as in iOS). There are many references in the web where it leads to the same conclusions, that BLE is not very stable implemented. https://stackoverflow.com/questions/23110295/difference-between-close-and-disconnect https://devzone.nordicsemi.com/f/nordic-q-a/38422/android-disconnect-and-close-do-not-disconnect https://medium.com/@martijn.van.welie/making-android-ble-work-part-2-47a3cdaade07 https://android.jlelse.eu/lessons-for-first-time-android-bluetooth-le-developers-i-learned-the-hard-way-fee07646624 https://punchthrough.com/android-ble-development-tips/ You have to play around with various methods, timing, callbacks, etc., to find a workable solution. I had hope that somebody has experienced the same issues, and knows probably a good and clean way to solve this. In above article from Martijn van Welie the Blessed library is recommended, as more iOS compatible and "friendly", so I have hope that such improved library may also exist for Delphi. If not, maybe some fixes for the BLE System libraries might exist, but I always try to avoid this, especially if they cannot be accessed easily. I think that the main issue that Delphi is used to make fast prototypes, but not stable applications for BLE in most cases, where these issues might be acceptable.

I'm just doing first tests on Samsung Galaxy S7 Edge, Samsung Galaxy S9 Plus, iPhone XS and iPhone 6 S. While IOS behaves quite friendly, no need to destroy the BluetoothLE device, on Android the devices not always get clean without destroying. Just to make it clear, it works with the destruction mehtod more or less stable, but I would like to find a less drastic and more reliable way. I'm working on the 4th generation of my libraries now, and I really wonder if there is no right way to connect/disconnect devices. Usually connecting once is no problem, but after disconnect sometimes work, sometimes don't sometimes need to wait about 20 sec., as described in that articla. If there is a golden way to cleanup, would be great know, I just make experiments with TJBluetoothAdapter.disable, but unfortunately Embarcadero had hidden many relevant classes in the implementation sections of the units. When I use the embarcadero samples, all is fine, unless I call device.disconnect, or the device disconnects by power off, or the device goes out-of-range etc. Connection is OK, but clean disconnection seems not really much considered in those libraries, or maybe even in the Android/iOS SDKs itself.

Maybe a small Sleep(200); in the repeat-until loop may help the OS to process the messageloop ?

Probably this is a somewhat newer version with some fixes, not sure about 32/64 Bit, but you could check. http://www.delphi4arab.net/forum/printthread.php?tid=9984 This may help as well. https://www.oipapio.com/question-6309338

Not sure is this may cause any issues as you describe, but the free version seems to accept only Android namespaces. http://www.fmxexpress.com/utility-to-generate-java-android-class-and-jar-file-interfaces-for-delphi-xe5-firemonkey/ Are you using the payed version ?

Not tested, but Seems that it is targeted at the lowest end of FMX compatibility. Even if it still may work, likely in the next update Android 4.4 is maybe no longer supported. I would consider that.

Nice, thanks for sharing. I see another thing, but maybe I had too fast overlooked the code ( TL;DR; ). I would assume that the files are not listed in the normal, sorted order, as they seems to pop-up at any time. So if the original order of the FileList is important, maybe you need to add a position indicator in the message ?

@Alexander Sviridenkov Have you considered to get a special HtmlComponents forum space here in DP ? Maybe you can check with Daniel about what the conditions would be to get such space. I think this is a great place for technical discussions.

Hi there, I an checking how existing apps could move flawlessly from APK towards the new AAB AppBundle, and I think it makes sense to have two different keys for one for app-signing (which is then hold at Google, after sign in to AppBundle) and one for uploading the app. There description of how the new upload keystore's might be generated, and how certificate can be extracted from such keystore from AndroidStudio. Unfortunately the RadStudio's "create new keystore" option will only create .keystore files, and the explanation above is for a keystore in .jks format. I naively thought that the keytool command above could work with any format (incl. .keystore), but I get a message that it cannot read the key. Firstly I must explain that there were at least two keytool's: one in Java JDK1.8.0_60 and one in Java JRE1.8.0_60 directory, I considered both should be 1:1 the same EXE, but they aren't. After some investigation I have choosen the JDK1.8.0_60, since this should be the right choice, but I can be wrong. Does anybody have a clue howto create a new .keystore and upload this to Google PlayStore, to be used as new upload keystore ? Maybe this can be done only by mailing to Google support and adding an upload certificate (which can be downloaded in the PlayStore AppSignature section). But that doesn't really make sense to me. For the app-signing first time, I can use the PEPK.jar tool, which can be downloaded to extract the certificate from a given .keystore, I would expect a similar mechanism for changing upload keystores, but I cannot find it.