Watch, Follow, &
Connect with Us

For forums, blogs and more please visit our
Developer Tools Community.


Welcome, Guest
Guest Settings
Help

Thread: Android, Splash and the "built in (FireMonkey) logo"


This question is answered.


Permlink Replies: 5 - Last Post: May 1, 2016 7:03 PM Last Post By: Eli M
Free Dorfman

Posts: 139
Registered: 2/4/12
Android, Splash and the "built in (FireMonkey) logo"  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Apr 27, 2016 3:59 PM
10 Seattle. FMX. Android.

Hey all. My struggles continue - and I am rebuilding my app from scratch - refactoring, re-structuring, and re-working it as I go.

One issue I'm encountering right away regards the splash screen. So:

In my very simple "splash only" version of the app, taken from http://www.uweraabe.de/Blog/2016/01/22/a-splash-form-in-firemonkey/
I have a splash screen that's visible for a bit, while the "main" form's FormCreate executes:
procedure TcsMainForm.FormCreate(Sender: TObject);
const
  N =
  {$IFDEF MSWINDOWS}
    2000000; {2,000,000}
  {$ELSE}
    10000; {10,000}
  {$ENDIF}
var
  x, y: integer;
  S: string;
begin
//mimic time-consuming startup code (this takes about 5 seconds on my machines)
 
for x := 1 to N do
  begin
  S := '';
  for y := 1 to 10 do
    S := (Random * Random / Random / Random).ToString;
  end;
end;


Under windows, thing's look as desired: Splash Screen, Main Form.

But what I get under Android is: Firemonkey Logo, Splash Screen, Main Form.

Is this the best I can hope for? I'm I going to need to set the "firemonkey startup image" to match my splash screen so that it looks like just one splash screen at startup? My guess is that even if I do that there's going to be a "flash" between the "firemonkey" splash and my splash.

Again - as always - your thoughts and help is very appreciated.

-Free Dorfman
Eli M

Posts: 1,346
Registered: 11/9/13
Re: Android, Splash and the "built in (FireMonkey) logo"
Correct
Click to report abuse...   Click to reply to this thread Reply
  Posted: Apr 30, 2016 10:12 PM   in response to: Free Dorfman in response to: Free Dorfman
Yes, pretty much. However, if you do the graphics on the two splash screens right it can instead just look like a progression. Like the Firemonkey form splash screen logo could be larger than the Android one so when it switches it will have a "grow" effect. Or it could be animated so when it switches it looks like a natural progression.

Free Dorfman wrote:
Is this the best I can hope for? I'm I going to need to set the "firemonkey startup image" to match my splash screen so that it looks like just one splash screen at startup My guess is that even if I do that there's going to be a "flash" between the "firemonkey" splash and my splash.
Free Dorfman

Posts: 139
Registered: 2/4/12
Re: Android, Splash and the "built in (FireMonkey) logo"  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Apr 30, 2016 11:02 PM   in response to: Eli M in response to: Eli M
Eli M wrote:
Yes, pretty much. However, if you do the graphics on the two splash screens right it can instead just look like a progression. Like the Firemonkey form splash screen logo could be larger than the Android one so when it switches it will have a "grow" effect. Or it could be animated so when it switches it looks like a natural progression.

Eli,

Thanks. I had pretty much come to those - uh - realizations.

It just kills me, though. Yet another example of something where it absolutely boggles my mind that there's no mention of it anywhere that's easily found.
Eli M

Posts: 1,346
Registered: 11/9/13
Re: Android, Splash and the "built in (FireMonkey) logo"  
Click to report abuse...   Click to reply to this thread Reply
  Posted: May 1, 2016 2:52 PM   in response to: Free Dorfman in response to: Free Dorfman
Mobile apps require a lot of polish regardless of the tool you use to build them. Splash screens are polish. There are all kinds of other polish tricks beyond what a normal app is. It's like deploying your Win32 app with an install wizard vs. just zipping it up.
Free Dorfman

Posts: 139
Registered: 2/4/12
Re: Android, Splash and the "built in (FireMonkey) logo"  
Click to report abuse...   Click to reply to this thread Reply
  Posted: May 1, 2016 5:16 PM   in response to: Eli M in response to: Eli M
Eli,

That's a great way of describing it. I guess I'm just real surprised that there aren't fully-realized sample apps out there that demonstrate these "polishes".

I spent years using D6 and this jump to 10 Seattle (actually XE7, XE8, then Seattle) has been a long, long series of struggles.

I think I made a big mistake by more or less jumping right in to building my first app. I "proto-built" it using D6 in about 10 hours.

I probably should've spent a couple of months just playing, learning, researching, reading, etc.

And while the above may be true, it still doesn't lessen my frustration.

See my latest issue: https://forums.embarcadero.com/message.jspa?messageID=823513#823513

Thanks,
-Free
Eli M

Posts: 1,346
Registered: 11/9/13
Re: Android, Splash and the "built in (FireMonkey) logo"  
Click to report abuse...   Click to reply to this thread Reply
  Posted: May 1, 2016 7:03 PM   in response to: Free Dorfman in response to: Free Dorfman
Basically it feels like Embarcadero tests their ~96 Firemonkey demos which each singularly test one feature (one sensor, the gestures, the camera, the effects, etc). Each individual feature demo works great. When you start combining all the features together into a single app you can run into unintended consequences. Some of those issues are actually mobile device limitations on XYZ device. Part of it is just knowing how mobile works so you can build accordingly.

When I build mobile apps with Delphi I build them like I did with D3-D7. Basic concepts. Simple code. Async message boxes. TForm.Show()/.Hide(). Async HTTP requests (I'm use to event based TCP/IP w/ ICS vs. Indy). TTabControl. Object pools. In some cases I modularized with TFrame. Creating objects is expensive on mobile so all the memory saving "good practice" tricks for Windows of creating and freeing objects don't necessarily help make a better app.

I use the same standard Windows events OnClick, OnMouseMove, OnKeyDown, etc. Sometimes you have to use the mobile device only events like OnTyping or the gestures for multitouch depending on which OS it is which is where the conditional compilation comes in.
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02