Jump to content

Stewag

Members
  • Content Count

    7
  • Joined

  • Last visited

Community Reputation

1 Neutral

Technical Information

  • Delphi-Version
    Delphi 12 Athens
  1. Stewag

    Styles bloating final packages

    Thank you Wak, but this is somewhat complicated and still not as effective as the procedure, that Patrick suggested. I implemented it now as follows: - remove stylebooks from all forms - add new Datamodules, one for each OS (DatamoduleAndroid, DatamoduleiOS, DatamoduleWindows) - put a stylebook with an OS-specific style on each of the datamodules - set UseStyleManager property on all stylebooks to true, to ensure that the style is valid for all forms - add this code to .FormCreate of each form: {$IFDEF MSWINDOWS} if not assigned(DataModuleWindows) then DataModuleWindows := TDataModuleWindows.Create(self); Stylebook := DataModuleWindows.StyleBook1 {$ENDIF} {$IFDEF ANDROID} if not assigned(DataModuleAndroid) then DataModuleAndroid := TDataModuleAndroid.Create(self); Stylebook := DataModuleAndroid.StyleBook1 {$ENDIF} {$IFDEF IOS} if not assigned(DataModuleiOS) then DataModuleiOS := TDataModuleIOS.Create(self); Stylebook := DataModuleiOS.StyleBook1 {$ENDIF} - and this to uses: {$IFDEF IOS} DMIOS, {$ENDIF} {$IFDEF ANDROID} DMAndroid, {$ENDIF} {$IFDEF MSWINDOWS} DMWINDOWS, {$ENDIF} This totally prevents bloating of packages with foreign styles and reduced my package size more than 15% 🙂
  2. Stewag

    Styles bloating final packages

    Hi Patrick, this sounds workable, I will try it. Thank you! Still I am puzzled as I don't think that many programmers are aware of this "style-addup". At least I never read about it. Even in Emba's "screens" code samples in GetIt, various styles are just added to the main form (screenshot). This seems to be a poorly documented topic?
  3. I develop a smartphone app for Android and iOS. In that, I use a stylebook and added Android, iOS and Windows styles to the master form (Windows only for development). Recently I found out, that the styles for other OS are also included in Android .apk and .aab packages! Here are the sizes of my Android packages. I deleted one style after the other, and the package got considerably smaller each time : .apk (Android development): Android, iOS and Windows styles: 15.2 MB Android and OS styles: 14.2 MB only Android style: 13.2 MB .aab (Android store): Android, iOS and Windows styles: 25.0 MB Android and OS styles: 14.2 MB: 23.1 MB only Android style: 21.3 MB I haven't tested yet if iOS .ipa is handled the same way. I would have expected, that styles of other OS would simply be ignored. Now I learned, that I can reduce the size of the store package by 15% simply by deleting other styles prior to compilation😯 This seems to be a major bug, isn't it?
  4. Stewag

    FMX views: Which one is applied?

    Oh, I was not aware, that it is yours I am even more thankful then! Have you tested the behaviour with a mobile app for general usage?
  5. Stewag

    FMX views: Which one is applied?

    Thank you Patrick, that is really helpful! I must admit that I was a little confused in the beginning, but I found a good tutorial, that shows TScaleLayout's function: https://www.youtube.com/watch?v=zaMaCGLZQt8&ab_channel=D%C3%A9veloppeurPascal Steffen
  6. Since long I wonder, how the different views that I configured for iOS and Android form-factors apply to displays, that do not fit in. For example, I saw at a friend's 6.5" Samsung that a "wrong" text size is used. I configured 5.8" and 6.8" views and would like to know which one (if any?) of the two was applied to the 6.5" device. I tried to find a way to display the currently applied fmx view, e.g. by pressing a label but have found no way yet. Maybe this is not possible as events are inherited? Or is there a way? I use TGrindPanelLayout to evenly spread components over the screen but have found no way yet, to scale text size for displays from 3.5 to 10 Inch displays other than using views. I'd be happy to abandon views and solve the text-size scaling problem with code. Any ideas for this out there?
  7. procedure TfMain.IOSTurn(Portrait: boolean); // Source: https://en.delphipraxis.net/topic/1796-firemonkey-change-ios-screen-rotation-at-runtime/ var LID: Pointer; begin if Portrait then begin Application.FormFactor.Orientations := [TScreenOrientation.Portrait, TScreenOrientation.InvertedPortrait]; if not TOSVersion.Check(16) then // iOS lower than 16 begin showmessage('Please turn phone back to portrait'); TurnIOStoPortrait := False; // turn off message to prevent multiple display end; end else begin Application.FormFactor.Orientations := [TScreenOrientation.Landscape, TScreenOrientation.InvertedLandscape]; end; if TOSVersion.Check(16) then // iOS Version 16 and up begin LID := NSObjectToID(TiOSHelper.sharedApplication.keyWindow.rootViewController); TUIViewControllerEx.Wrap(LID).setNeedsUpdateOfSupportedInterfaceOrientations; end else // iOS 13: no automatic rotation. Not tested for iOS<13 begin TUIViewController.OCClass.attemptRotationToDeviceOrientation; if TabControl1.ActiveTab.Name = 'XXX' then // limit message to specific tab showmessage('Please turn phone to landscape'); end end; Dave's code works magnificently - thank you Dave! Here is an alternative procedure to Dave's Button1Click() that works both ways and includes messages to rotate the phone manually. This is necessary for iOS lower than 16, where the content but not the display is rotated by the code. In IOS 16 and up, rotation is done smoothly automatically. I could only test iOS 13 though, maybe someone can extend the code to iOS < 13? Steffen
×