Rollo62

My greetings and best wishes to you ..., unfortunately I'm on renewal

Thanks for the great article, also me I like TPath, TPathData a lot, which gives much more flexibility in UI design.
 

1. In your list of alternatives you missed HtmlComponents, which also include a quite powerful SVG engine.

2. TPathData is really a great tool, but I found out a while ago that it doesn't seems to support all SVG curve types yet.
It seems to support the cubic bezier curves, like this from string to internal format:

'C':
            begin
              CurvePoint1 := GetPointFromString(PathString, Pos);
              CurvePoint2 := GetPointFromString(PathString, Pos);
              CurveTo(CurvePoint1, CurvePoint2, GetPointFromString(PathString, Pos));
              while HasRelativeOffset(PathString, Pos) do
              begin
                CurvePoint1 := GetPointFromString(PathString, Pos);
                CurvePoint2 := GetPointFromString(PathString, Pos);
                CurveTo(CurvePoint1, CurvePoint2, GetPointFromString(PathString, Pos));
              end;
            end;
          'c':
            begin
              CurvePoint1 := GetPointFromString(PathString, Pos);
              CurvePoint2 := GetPointFromString(PathString, Pos);
              CurveToRel(CurvePoint1, CurvePoint2, GetPointFromString(PathString, Pos));
              while HasRelativeOffset(PathString, Pos) do
              begin
                CurvePoint1 := GetPointFromString(PathString, Pos);
                CurvePoint2 := GetPointFromString(PathString, Pos);
                CurveToRel(CurvePoint1, CurvePoint2, GetPointFromString(PathString, Pos));
              end;
            end;

But the quadratic bezier curves seems not be implemented right now:

'Q', 'q':
            begin
              GetPointFromString(PathString, Pos);
              GetPointFromString(PathString, Pos);
            end;
          'T', 't': GetPointFromString(PathString, Pos);

Maybe this is a feature or a bug, I hope you have some more insight about the SVG details, since you delved more deeply into it.
My original thought was that maybe quadratic and cubic bezier curves are compatible, and I could replace one with the other,
but I had no time yet to proof this.
Why else should Embarcadero miss these implementations ?

However, I totally agree and can only recommend to use more SVG via TPath in your apps.

Advantages are for me:

- very likely less memory footprint than many bitmaps of same object (x1.0, x2.0, x3.0, red version,  green version, ...)

- can change stroke/fill color on demand

- can be dynamically changed, giving a kind of animation

At least those old numeric systems were activating the mental arithmetic in everyday life.

In FMX have you checked the Application Events with OrientationChange under FMX.Platform ?

They fire  on iOS and Android,  Not sure about Wintel .

Ok, finally its back again.

But I had to

- remove the updated XCode 11.2.1 before (the XIP extraction and copy method seems to have some flaws, altough XCode runs fine)

   by throwing XCode.app in the waste bin and clean up some remains, old ScratchDir, etc.

- re-boot VM, to be on the safe side
- re-install XCode 11.2.1 from the AppStore
- re-boot iPhone
- re-connect iPhone, XCode is preparing (which is a good sign).

- Close RadStudio

- Reboot RadStudio VM (to be on the safe side)

- Restart and open RadStudio

- Remove in SDK Manager the old 13.2 SDK's

- Add new 13.2. SDK

- Build RELEASE

- Deploy with Transporter (or old ApplicationLoader)

- Done

I think the problem my occured by unzipping XIB file and overwriting the old XCode (although this was recommened in several places).

It seems that the SDK or tools were not updated.

Better if I did a complete cleanup of XCode before, but since that was not available in the AppStore, it was not really a "usual install",

so I avoided to cleanup in the first place.

So I will be careful with Apple's hurry up fixes in the future, if Apple only would let me keep my old version running (which they didn't).

Anyway, getting back productive now, thats good for me, and maybe helps other to avoid such scenario.

29 minutes ago, Hans♫ said:

Sorry that I did not make my self clear. I was commenting on your post about how to get Application Loader.

Yes, no problem.  Thanks for help anyway.

Regarding Transporter (and the whole deployment), maybe this file is interesting too.

Regarding the XCode 11.2.1 Problem, I just downloaded from official AppStore, no more XCode 11.2.1 DM Seed version needed.

! Available since  1 day, after issues yesterday ...

Why can Apple not give at least a reasonable timespan to allow updates when developers are ready for it,
instead forcing us to update but not delivering any product.

Sometimes I think I'm in the wrong place, in the wrong time ...

4 hours ago, Hans♫ said:

The new method to upload apps to App Store, is the new app "Transporter". I have used it successfully to upload an iOS app to App Store.

Just download it from Mac App Store, it works the same way as Application Loader.

Ok, the problem was not the upload to the AppStore, that always worked.
But I got the message that wron SDK or other stuff was used for compiling.
It seems that I have downloaded XCode 13.2.1 GM Seed, from XIP file, but that didn'T really update the SDKs, which may cause such issue.
I soon will check further whats going on.

Update:

Ok, now the XCode 11.2.1 seems to be officially in the AppStore, and I just try to install it.
No more fancy XCode 11.2.1 GM Seek stuff, which was the only way yesterday.  What a bu....hit ...

Stupid question: Does Temp really exist (typo, wrong UTF8-character, etc.) ?

I usually put a FileExists before such things, to be sure.

'C:\Temp\Notepad.reg'

I think that depends a lot on what languages you are targeting.

See i18n for howto handle different pluralities in other languages well, this can get very scaring.

Alt least I can confirm the process so far:

https://stackoverflow.com/questions/43663097/how-to-install-xcode-from-xip-file

1. Download the XCode.xip file from https://developer.apple.com/download/ after sign in.

2. Double-click the XCode.xip file to unpack it

3. After unpacking you see the XCode.app, which can be simple copied abd overwrite the existing old app under Applications

So far XCode 11.2.1 start and shows up normally, lets see what happens next.

4. XCode opened looks normal, all is there.

   .xip file seems to be a kind of patch, not a real installation, the additional tools were not downloaded automaticall.

5. Connection phone showed yelloe prepare header very fast, seems no new DebugImage was loaded

6. RadStudio SDK Manager shows option to add SDK 13.2.

    I decided to keep the old SDK 13.2 and update local file cache

7. Build project and debug, OK (needs more testing, but complex app works normally)

8. Build release works normally

9. Upload to AppStore: not OK

    Here comes the catch, it came back with same error message as above (wrong commandline tools, wrong SDK).

10. So I need to know how to probably re-load commandline tools in XCode.

      And I have to check what happens if I add a second 13.2 SDK entry in SD_K Manager (where I have a bad feeling in my tummy).
      Or if there is anything else which could update the SDK.

Maybe tomorrow I got more insights, for today I lost enough hours, and will go to sleep.
If all doesn't work, I will try a complete, clean re-install of the XCode.xip file, which will cost another hour, but who cares (Apple does not, for sure ...)

Again Apple made my day 🤬

Running perfectly with XCode 11.2, until suddenlyI see this message:

As far as I know XCode 11.2 is NO beta version, I already made uploads to AppStore a few times.

Was deprecated for some reasons (I really don't want to know).

Now it forces me to install XCode 11.2.1 (which I cannot find in the store, by the way).

Which I can find here

https://developer.apple.com/documentation/xcode_release_notes/xcode_11_2_1_gm_seed_release_notes/

https://9to5mac.com/2019/11/05/apple-xcode-critical-update/

Everybody who still believes that Apple has the better software lives on another parallel planet.

It looks as this 11.2.1 could be a beta version, and I still cannot upload anything.
Shall I spend another half a day to find that out ?

Apple really putting me in serious trouble, since I cannot meet my schedules by this beta bug desaster in the last weeks.
Maybe somebody has some recommendations, or at least the right place where to download XCode 11.2.1.

Update:

This was the right answer, where to find it.  By searching the member download area I can't see it.

https://apple.stackexchange.com/questions/374515/why-is-xcode-11-2-1-not-appearing-in-the-app-store-updates-tab

Quote

Xcode 11.2.1 GM seed is available at https://developer.apple.com/download/ after sign in.

I just started (and stopped) the download.

Still the question what to do, Shall I update and can I install apps again ?

Not sure what you require, maybe that helps as base, but its VCL ?

In FMX you simply can drop label on edit or vice-versa, to create a combined component.
With layout align and margins you can do a lot.

12 minutes ago, Yaron said:

I doubt it will override the 64bit version, they request the version be the same to prevent people from releasing mismatched versions by accident.

 

But I cannot proceed using the same version code.

3 minutes ago, Dalija Prasnikar said:

Official documentation https://developer.android.com/google/play/publishing/multiple-apks

Yes, I have to study this more deeply, but I'M not sure if that is related to the same apk.
Already the first view showas all these rules, I try to confirm as far as I can get today in red color:

Quote

Rules for multiple APKs

Before you publish multiple APKs for your application, you need to understand the following rules:

• All APKs you publish for the same application must have the same package name and be signed with the same certificate key.: OK
• Each APK must have a different version code, specified by the android:versionCode attribute.: OK, this can be done, I will try.
• Each APK must not exactly match the configuration support of another APK. Not sure what that means, TL;DR

  That is, each APK must declare slightly different support for at least one of the supported Google Play filters (listed above).

  Usually, you will differentiate your APKs based on a specific characteristic (such as the supported texture compression formats), and thus, each APK will declare support for different devices. However, it's OK to publish multiple APKs that overlap their support slightly. When two APKs do overlap (they support some of the same device configurations), a device that falls within that overlap range will receive the APK with a higher version code (defined by android:versionCode).

• You cannot activate a new APK that has a version code lower than that of the APK it's replacing. For example, say you have an active APK for screen sizes small - normal with version code 0400, then try to replace it with an APK for the same screen sizes with version code 0300. This raises an error, because it means users of the previous APK will not be able to update the application.
• An APK that requires a higher API level must have a higher version code. OK

  This is true only when either: the APKs differ based only on the supported API levels (no other supported filters distinguish the APKs from each other) or when the APKs do use another supported filter, but there is an overlap between the APKs within that filter.

  This is important because a user's device receives an application update from Google Play only if the version code for the APK on Google Play is higher than the version code of the APK currently on the device. This ensures that if a device receives a system update that then qualifies it to install the APK for higher API levels, the device receives an application update because the version code increases.

  Note: The size of the version code increase is irrelevant; it simply needs to be larger in the version that supports higher API levels.

  Here are some examples:

  • If an APK you've uploaded for API levels 16 and above (Android 4.1.x+) has a version code of 0400, then an APK for API levels 21 and above (Android 5.0+) must be 0401 or greater. In this case, the API level is the only supported filter used, so the version codes must increase in correlation with the API level support for each APK, so that users get an update when they receive a system update.
  • If you have one APK that's for API level 16 (and above) and small - large screens, and another APK for API level 21 (and above) and large - xlarge screens, then the version codes must increase in correlation with the API levels. In this case, the API level filter is used to distinguish each APK, but so is the screen size. Because the screen sizes overlap (both APKs support large screens), the version codes must still be in order. This ensures that a large screen device that receives a system update to API level 21 will receive an update for the second APK.
  • If you have one APK that's for API level 16 (and above) and small - normal screens, and another APK for API level 21 (and above) and large - xlarge screens, then the version codes do not need to increase in correlation with the API levels. Because there is no overlap within the screen size filter, there are no devices that could potentially move between these two APKs, so there's no need for the version codes to increase from the lower API level to the higher API level.
  • If you have one APK that's for API level 16 (and above) and ARMv7 CPUs, and another APK for API level 21 (and above) and ARMv5TE CPUs, then the version codes must increase in correlation with the API levels. In this case, the API level filter is used to distinguish each APK, but so is the CPU architecture. Because an APK with ARMv5TE libraries is compatible with devices that have an ARMv7 CPU, the APKs overlap on this characteristic. As such, the version code for the APK that supports API level 21 and above must be higher. This ensures that a device with an ARMv7 CPU that receives a system update to API level 21 will receive an update for the second APK that's designed for API level 21. However, because this kind of update results in the ARMv7 device using an APK that's not fully optimized for that device's CPU, you should provide an APK for both the ARMv5TE and the ARMv7 architecture at each API level in order to optimize the app performance on each CPU. Note: This applies only when comparing APKs with the ARMv5TE and ARMv7 libraries, and not when comparing other native libraries.

Failure to abide by the above rules results in an error on the Google Play Console when you activate your APKs—you will be unable to publish your application until you resolve the error.

There are other conflicts that might occur when you activate your APKs, but which will result in warnings rather than errors. Warnings can be caused by the following:

• When you modify an APK to "shrink" the support for a device's characteristics and no other APKs support the devices that then fall outside the supported range. For example, if an APK currently supports small and normal size screens and you change it to support only small screens, then you have shrunk the pool of supported devices and some devices will no longer see your application on Google Play. You can resolve this by adding another APK that supports normal size screens so that all previously-supported devices are still supported.
• When there are "overlaps" between two or more APKs. For example, if an APK supports screen sizes small, normal, and large, while another APK supports sizes large and xlarge, there is an overlap, because both APKs support large screens. If you do not resolve this, then devices that qualify for both APKs (large screen devices in the example) will receive whichever APK has the highest version code.

  Note: If you're creating separate APKs for different CPU architectures, be aware that an APK for ARMv5TE will overlap with an APK for ARMv7. That is, an APK designed for ARMv5TE is compatible with an ARMv7 device, but the reverse is not true (an APK with only the ARMv7 libraries is not compatible with an ARMv5TE device).

When such conflicts occur, you will see a warning message, but you can still publish your application.

On 11/6/2019 at 2:18 PM, Dalija Prasnikar said:

Play Store allows uploading separate APKs, but using AppBundle is easier.

I just tried that out, with same app, compiled to 32-Bit and 64-Bit.
1. I uploaded 64-Bit version to internal test: All OK
2. I uploaded 32-Bit version to internal test: Failure: "You have already uploade app with same version code"

This is what I expected, so if you says its possible to upload separate 64- and 32-Bit apps, can please explain how ?
Of coarse I could upload 32-Bit with new version code, but isn't this new version then overriding the 64-version as well ?

Hi there,

does anybody know the status of this app for measuring energy consumption of certain apps, is it cancelled or no longer updated ?

In the PlayStore I cannot find it any longer.

I think its cancelled or sold into an other product, so maybe someone knows good working alternatives to measure power consumption of other apps.

To whom it may concern ...

http://www.se.uni-oldenburg.de/documents/saksonov-MA2014.pdf

@Dalija Prasnikar

Great, thanks for clarification. Never seen such feature to have separate APK, but good to know.

However, the AppBundle should be the way to go.

1 hour ago, Marco Cantu said:

We see a lot of recent Android devices with 64-bit CPUs but 32-bit OS. Odd, I know, I wasn't aware is this was so widespread.

Would that mean that when NOT using the new AppBundle feature, and
the new Apps will be 64-Bit in coming Rx10.3.x,

then these 64-Bit APK won't run on those devices ?

Or will the coming Rx10.3.x version APK contain both, 32- and 64-Bit code ?

That would mean "AppBundle" is a must to support all devices with such 32-on-64 Bit OS, is that correct ?

I don't know if Aerserve is still active and running with Rio, never checked thant.

Maybe somebody has more info about this ?

What exactly are you looking for ?

For FMX on Mobile, there is TBannerAd, is this what you are looking for ?

2 hours ago, Uwe Raabe said:

AFAIK is the IDE license bound to the machine name only. I often move Delphi VMs to other drives without any problems. There must have happened something inside the VM to trigger this.

I have many copies of VM, if I understand your issue right, mainly for backup and "snapshots" for updates etc.

No problem to start a newly copied VM, or to install into older, clean VM, just tell VmWare "I have moved it" and it should be fine.

! But you should avoid to have multiple VM running at the same time.

Just to let you know:

About 4 days ago the official XCode 11.2 came out, which I just installed and tested.

Now iOS 13.2 works fine again, XCode can deploy the debug image, and I can debug and test as usual.

The problem was that my iPhone was installing a beta version (13.2), which was only supported by a beta XCode 11.2 at that time, without any notice.

Maybe the reason was that Apple released the IOS 13.2 (final) BEFORE the according XCode 11.2 was released.

During that time gap this will break debugging, affect app-store approvals (if I would have installed an XCode beta release), and so on.

Various headaches, so I will check how I could better prevent unwanted updates in the future.

Good that you solved your issue with OSM.

However, its strange that your apps crash on most of these phones.
I have not all of your phones in the list, but maybe 40-50%, OK the MapView is not the main purpose in my apps. so its probably not stretched to the max.

I would expect anything like  > Galaxy 7 should make not such issues with GPU at all, when following the advices above.
Somethimes the issues may come from a total different side, are you sure you had a valid GoogleMaps Token and defined correct in the dashboard ?

Have you tried a new, blank app, with MapView only ?

Probably yes, its NOT an Delphi issue.

But I cannot get even close to this, since XCode doesn't want to speak with the iPhone at all.

It cannot even fix anything or build and compile an empty XCode app.

Maybe one way would be to install older debug images on the phone, but I still have not figured out how that can be done

in 100% safe and secure way.
No time at the moment to fumble around with iOS, I still have to test Android 64 compatibility.

When you wont get ready in time with your XCode 11 installation and iOS 13.2 preparation of the phone,

just watch this.

That happens to me right now,

and I just decide to choose the 15 minutes wait version, since the other options didn't help

I should clarify that this is another Apple issue (not Delphi), as there were too many issues in iOS 13 for the last weeks.
Would like to get on going soon.

Edit:

Yes it seems IOS 13.2 was a Beta version, but it was installing with no special note.
Of coarse now XCode 11.1 cannot get development access to this, and I don't want to install the next XCode 11.1 beta really.

Nevertheless, I will have to forget my iPhone test device for a while, and check further with another one.

Unbelievable that my phone could make a Beta update, without presenting the stable version as normally, or any question before.

So my advice: Never do updates on iOS beta versions, or you're in trouble.

1 hour ago, Mike Torrettinni said:

I'm not sure what you have in mind... if I have methods with parameters like:

(string, string, integer)

(integer, integer, integer, string)

.... and all other options of number and type of parameters.

You were asking for options, and if the signatures are well defined and limited thats a possible option too.

So that meant you could use overloads for the most common ones.
E.g. I try use mostly compatible signatures, also for different domains in my projects.

The array of const can catch then all the rest.