Rollo62

I use VM Pro too, and it works perfectly here under Mac and Win for the last versions. I think the Pro wouldn't be necessary for a simple VM, but you have to check the different features. E.g. I can run Mac, Win, Linus guests w/o any problem. Which is very convenient if you do mobile development, and have to check plenty of new versions from all OS and different sides. So far Vmware is my stable pole in all this mess. Every year there will be a new main version, and from time to time you see some service updates as well, and so far I followed all the updates. The advantage is also that the images can be used from Mac and from Win (Vmware Fusion, and Vmware Workstation), so the finetuned images could be reused if needed. My only recommendation is to use a FAST and LARGE SSD, to have more fun with switching between the Vm-images. In my old setup I had a too small SSD (500GB only), which practically only can hold 3 VM at a time. I switched to a fast 2TB SSD now, which allows very easy to make intermediate backups, e.g. for Win10 update 1803 to 1809, or the like. You're always safe, and never had to fear that you kill your current working environment. But I also used to work with external SSD via USB3.x, which is nearly as fast as internal SSD, and allows to fastly switch to older projects, by plugging in a USB drive.

If you mean by your above comment that MacBook Pro would be the perfect environment, I would completely sign that statement. Its absolutely great to switch between complete VM machines back and forth in milliseconds, and you have all the environments under one hood accessible. Unfortunaltely the only the keyboard quality is not my favorite, but one can get used to it. I would vote for the MB Pro as development workstation: (+1) ! BUT WAIT: Only recently Apple's designers decided to destroy their complete MB business, by adding the fancy TouchBar. Since then there is no more ESC, not F1 .. F12 key, only a flat surface w/o haptic feedback, That configuration is completely useless, not only for development/debugging, but I would say also for most productive works, like graphics design, webdesign, video production, etc. If you would like to pay more for a simple eye-catching internet browser, then please do, but IMHO the original MB Pro spirit is dead. I would vote against the MB Pro (w/ touchbar): (-1) So how to solve this paradox of the most valuable company in the world ? Maybe by purchasing a special Logitech multi-device keyboard that make MB Pro workable again ? Unfortunately there seems to be no real alternative for the keyboard with trackpad in the market (probably because of Apple has patented every slight shaky finger movement as gesture, and prevent any useful hardware extension by their extensivly costly MiFi program). Some day in the distant future there might be a good external keyboard/trackpad solution in the market, or in the near future Apple may have moved from hardware manufacturer to cloud services provider business completely. You never know

Maybe this can be useful too.

How can we fake Delphi apps to get recognized as Unity from the Google algorithm ? 😁

Although macOS 64 would be nice to have, but only very few seem to use it really. I've started a poll here, but only few people were interested. For Android I would assume there is much more interest, and failing this deadline would be a bigger problem for Embarcadero.

I understand above line that Unity has a special permission to generate code in 32-Bit until 2021, or did I get that wrong ? What I mean is Delphi should be listed for such permission too. Why has Unity such permssion ? Maybe simply because somebody as Unity was earger to ask Google about it.

We have constantly updates in our apps, so that won't help a lot. Any by the way: Delphi should be listed here too.

Have you checked recently ? I will do here too and let you know if anything moves, its about time to get closer to the next version issues. If our apps would be cancelled from the PlayStore would be a big desaster.

I had seen this too, and PlayStore still accepted that. Maybe this is only a warning, since it doesn't sound that AndroidAppBundle has to be used from August. I hope it doesn't come along with the 64-Bit requirement, although it would make sense to have an updated bundle indeed. Of coarse also Delphi should be supporting this in the near future. Lets see what their time schedule is. Probably I have to check if the next Beta-Version is already available.

Beauty is in the eye of the observer: That is problem no. 1. Engineers, Designers, Managers, Bosses (and customers) have all different eyes

I would think Add is a Write Operation, not a ReadLock ..

Dear all, a CrossPost in the German DP. I want to use a simple vibration-feedback, aka Peek und Pop, but I'm unsure with which method this may run on all iPhone devices. There is the possibility to use AudioServicesPlaySystemSound, https://stackoverflow.com/questions/33425586/vibrate-iphone-6s-manually-like-peek-and-pop which would be perfectly OK for me. But I had to note that this doesn't seem to work on all devices anymore. There is also the TapticEngine, which can be used on newer devices (I think >= iOS10 / iPhone7). https://developer.apple.com/documentation/uikit/uiimpactfeedbackgenerator https://www.delphipraxis.net/192200-uiimpact-feedback-generator-fehlende-klasse-deklarieren-und-nutzen.html There seems to exist also a way via 3DTouch. https://developer.apple.com/library/archive/documentation/UserExperience/Conceptual/Adopting3DTouchOniPhone/3DTouchAPIs.html Which method might guarantee that it will work on all devices and versions ?

My clients with that issue had newer phones, iPhoneX even, definitvely >= iOS 11. Anyway, there were not too many complaints about missing vibration function, so I hope its not a general issue. Probably the users switched it off somehow or had some other apps interfearing with vibration, unfortunately they couldn't give me some clear explanation of the errors and configurations at the hotline. I am still aware and on the hunt for more strange behaviours with my clients in the future, but some issues like that might be solved by time automatically too (hopefully)

Yes I used this one. So you know any reasons why this might work on some iPhones and some not ? These were comments from users, i dont have such iPhones in hand. Its working fine on all my test devices.

Hi there, I was trying to package the notifications in a more easy to handle function, to be set at runtime. What I noticed was that the NotificationCenter doesn'T seem to work with this method (at least I checked iOS only): FNotificationCenter := TNotificationCenter.Create( nil ); FNotificationCenter.OnReceiveLocalNotification := EvOnReceiveLocalNotification; The internal methid shows a class constructor: class constructor TCustomNotificationCenter.Create; begin {$IF defined(IOS) or defined(ANDROID)} // We need to create the NotificationCenter to register the external notification messages from the system in the app initialization TBaseNotificationCenter.InternalGetInstance; {$ENDIF} end; But this seems never be called, neither the normal Create of the Notification center constructor. constructor TBaseNotificationCenter.Create; begin inherited; TMessageManager.DefaultManager.SubscribeToMessage(TMessage<TNotification>, DoReceiveLocalNotification); end; Maybe somebody knows how it would be possible to create the notification center via runtime safely ? What works is if I pass the normal IDE component to my class, then it works correctly. It seems to me that there are maybe special requirements on the sequence or timing of the creation, or maybe it needs an Owner to work correctly.

Not really, I would say. TNotificationCenter is considered to be used in DesignTime only. EMBT would respond to this issue as "by design" probably

What about using a 9-patch images: http://docwiki.embarcadero.com/RADStudio/Rio/de/Verwenden_von_9-Patch-Grafiken_in_Android http://docwiki.embarcadero.com/RADStudio/Rio/de/Anwendungsoptionen https://stackoverflow.com/questions/13487124/android-splash-screen-sizes-for-ldpi-mdpi-hdpi-xhdpi-displays-eg-1024x76 https://github.com/yypbd/yypbd-Delphi-NinePatch https://medium.com/@101/splash-screen-in-android-769d3b0bafd0 But I think the basic problem stays the same, you won't get a pixel-perfect display on all devices (if that is needed). P.S.: I would consider if this is worth the efford for an image visible only once at startup. (but customers are kings ....)

I think I found the reason: It has to do with the Loaded function when components are created procedure TNotificationCenterIOS.DidFormsLoad; begin FIsApplicationLoaded := True; NotifyDelayedNotifications; end; procedure TNotificationCenterIOS.DoLoaded; begin inherited; DidFormsLoad; end; procedure TCustomNotificationCenter.DoLoaded; begin if Supported then FPlatformNotificationCenter.DoLoaded; //<-- This is never loaded when created during runtime end; I have to simulate the Loaded function, so below is the workaround that fixes the behaviour: procedure TForm1.Notification_Center_Create( AOwner: TComponent ); begin FNotificationCenter := TNotificationCenter.Create( AOwner ); FNotificationCenter.OnReceiveLocalNotification := EvOnReceiveLocalNotification; FNotificationCenter.Loaded; //<-- this works and simulates the component "loaded" state end; I hope that it might be useful for somebody else too. All this was not nice to find, because the libraries also couldn't be debugged in my setting, for some reason. Usually I can debug all the included libraries. Anyway, I can get back to more productive coding again

I just made some more tests. I've tried to create a TNotificationCenter variable, created with Owner, like this: procedure TForm1.FormCreate(Sender: TObject); begin MyNotification_Center_Create( Self ); end; procedure TForm1.Notification_Center_Create( AOwner: TComponent ); begin FNotificationCenter := TNotificationCenter.Create( AOwner ); FNotificationCenter.OnReceiveLocalNotification := EvOnReceiveLocalNotification; end; ! But on the Form I have NOT dropped any TNotificationCenter component. OK: Creation works fine OK: Sending local notification works fine OK: When in background & pressing a notification, the app is shown nOK: When in background & pressing a notification, EvOnReceiveLocalNotification is never fired. With a second test, same app, the only difference is: I drop a TNotificationCenter component on the form Just drop component No further "uses" appear Not touching this component at all: No Event handler, no method call, not changing properties ! Suddenly the same code from above magically works. OK: When in background & pressing a notification, EvOnReceiveLocalNotification is fired as it should (before BecameActive). It seems that somehow dropping the component on the form changes something, maybe creation order or registrations. Perhaps somebody has a clue how I could get rid of the designtime component here ? Edit: Another test It also worked as expected without the owner: FNotificationCenter := TNotificationCenter.Create( nil ); <-- Works also, when somewhere a TNotificationCenter was dropped The only difference is that the component needs to be dropped on the main form, to get the event working.

Maybe some vendors may use their own USB-drivers, have you checked this one ? I use Samsung devices here too, long time ago I had to consider to install Samsung ADB driver, since I few years I never got into this issue anymore (eiter I have current Samsung driver, or Samsung switched to Google driver too). I hope that nasty issue keeps "magically" solved by EMBT anf Google for the future

@TurboMagic Approved by Google and customers of the many Apps in the PlayStore using it 1:1. I wouldnt bother too much about the why' s. @Dalija Prasnikar +1 Use same strategy here too. I didnt found a reliable way to scale and fit real images in all screensizes. Would like to have that too, but its way too risky to get strange results in one of the 10000 devices out there.

I get used to non-modal dialogs via anonymous procs. Use them in mobile as well as desktop. Its the better concept

Maybe this may help you https://developer.android.com/guide/practices/screens_support.html#DesigningResources https://support.google.com/googleplay/android-developer/answer/1078870?hl=en&ref_topic=2897459 https://developer.android.com/training/multiscreen/screensizes I use the same image sizes as FMX bin\Artwork\Android provides, because thats approved and should be working.

I can only partly agree to this. In new projects I use meanwhile 90% FMX, and simply avoid all the buggy parts, by using the essential components only. Regarding VCL-compatibility, I would love to see this vice versa, maybe make VCL more compatible to FMX. Indeed a few simple changes could make code much more compatible, but the question is if its worth the efford.

then also try out "while .. do" loops, they can replace for and repeat loops both