Dave Nottage

Is now live! https://github.com/DelphiWorlds/Kastri/tree/master/Demos/GoogleSignIn

Which is sadly out of date (applies to Delphi 10.2). The implementation I'm working on should work in Delphi 11.x, and is more simplified than the Grijjy's.

I have imports there, however an implementation for Google Sign-In is still coming..

FB4D is also (according to the docs) dependent on linking static libraries for SSL, for iOS*. This is at odds with JOSE, which is dependent on dynamic linking. For it to work on iOS, one will need to be changed. *This statement in FB4D seems odd: "The library files libcrypto.a and libssl.a must be deployed within the package". Statically linked files do not need to be deployed. You might also like to see this.

It's possible it's because your app crashed. When switching back to it, does it appear as if the app is restarting? I seem to recall OnSaveState being unreliable anyway due to it not being called at all if the app is "swipe closed" (I could be wrong). It might be more reliable to persist anything you need restored as soon as a change has occurred. Using FireDAC, SQLite databases are by default in auto-commit mode, i.e. any changes should be saved immediately.

https://developer.android.com/reference/android/Manifest.permission#ACCESS_BACKGROUND_LOCATION

I'm confused with your last reply: are you still receiving the error? Also, which version of Delphi are you using?

You should be able to detect whether they've granted "allow all the time" by using: PermissionService.IsPermissionGranted('android.permission.ACCESS_BACKGROUND_LOCATION'); The CrossPlatformLocation demo in Kastri has logic to ensure the user is aware that it will work only if it is granted, starting from the RequestPermissions method, here. If they've already granted sufficient permissions, it just "falls through" to starting the location services.

Crashes before anything at all is shown. This is from the event log: Faulting application name: RightNote.exe, version: 6.1.1.0, time stamp: 0x645ac479 Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000 Exception code: 0xc0000409 Fault offset: 0x77945948 Faulting process id: 0x0x1598 Faulting application start time: 0x0x1D9ADE7EB1F95C8 Faulting application path: C:\Utils\RightNote\RightNote.exe Faulting module path: unknown Report Id: 32f9e65a-e8cf-4ed5-8bf2-af8598ebae0c Faulting package full name: Faulting package-relative application ID: According to this, it's a "fail fast" exception. I assume from your original post you're using Delphi 10.4?

There's a number of ways to achieve it, and most involve changing the position of the control, or more likely a control that contains it, since other controls will usually be included in the same "container". For example, you might have a label next to, or above, the edit. Having them both contained inside the same control means that the "container" should be moved "upwards" sufficiently so that the edit appears above the keyboard. There is a demo here, that helps make all this close to automatic. Note that the demo uses code from the Features\VKObserver folder of the same repo. It's not perfect, however it is useful for most scenarios.

Macbook M1

Yes. I'm running a Windows 11 ARM VM and Win32 and Win64 apps built with Delphi are running fine. Perhaps your app is not starting for some other reason?

I figured it had to be fairly simple. Can someone poke holes in this? It assumes you're passing a valid value for ADayOfWeek. Also assumes the start/end dates should count uses System.DateUtils; function DayOfWeekCountBetween(const ADayOfWeek: Word; const ANow, AThen: TDateTime): Word; var LDate: TDateTime; begin Result := 0; if AThen >= ANow then begin LDate := ANow; repeat if DayOfWeek(LDate) = ADayOfWeek then Inc(Result); LDate := LDate + 1; until LDate > AThen; end else Result := DayOfWeekCountBetween(ADayOfWeek, AThen, ANow); end;

You'd need to typecast it to a TMemoryStream in order to do that, e.g: if LResponse.ContentStream is TMemoryStream then TMemoryStream(LResponse.ContentStream).SaveToFile(LFileName) // else the implementation has changed ;-)

The fix in 11.2 is essentially the same as was suggested. The problem is that UIImageToBitmapSurface was not fixed, as opposed to UIImageToBitmap (directly below it), which was.

Yes, like I said earlier:

Unfortunately, just because it's on the palette when the platform is selected does not mean it works on that platform - it just means the platform attribute is set on the component.

That's an alternative, but the discussion was about whether or not TPopupMenu works. The documentation is incorrect, the advice on the TRichView forum is correct - it's not supported on Android (or iOS)

Happens way too often for me - received one today. I'm at the point where I can recognise their "scam" and just ignore it.

Ouch. I'm hoping that's an error...

Which document, and what does it state, exactly?

There is none, since they're stored in external storage, i.e. external to the app. Normally you would deploy files to the OBB folder using APK Expansion, however this method is deprecated and Play Store apps must use Play Feature Delivery or Play Asset Delivery. If you're interested in delivering files this way with Delphi, I have an implementation/demo here. Warning: it's not for the faint of heart 🙂

Whilst searching for something else, I came across this reply. If you haven't implemented this yet, I'll take a look.

As long as the font file is deployed to ./assets/internal and that file has the same name as the font name, with the extension .otf or .ttf, then it should work without changing FMX.FontGlyphs.android

See this demo: https://github.com/DelphiWorlds/HowTo/tree/main/Demos/AndroidContent You could add code to persist the results to a file (or files) somewhere.