Dipping my toes in

Yesterday I made my first iOS application (for my use only).

Pros:

  • Same IDE and pretty much the same principles as I’m used to.
  • Love the ability to “Run” as 64-Bit even without the debugger.

Cons:

  • It’s very hard to lay out the interface, controls go all over the place, they sometimes don’t stay where you put them, resizing can get a bit funky.
  • The difference in the framework to what I’m used to, slows down development a lot.
  • The documentation is wrong in so many places. Like new iOSTableCellData() doesn’t work, instead iOSTable.createCell() does.

Some things are far more complicated than they should be, for instance displaying the result of a calculation.

Dim d as double = a * b something.text = d.toText( locale.current, "0.00" )
As opposed to

something.text = format( a * b, "0.00" )

So I ended up writing my own “format” function as it was used a lot.

btw, I’m not looking to do full time iOS development, I just wanted a small app in the car and now I got it. But it took much longer than it should have IMHO. Hopefully this information can be useful to Xojo.

Lock them when you have them where you want them

We’ve discussed changes to how things work for iOS layouts to make it less annoying since it literally solves the layout as you move controls and the constraints in place can cause others to move & … yeah it gets frustrating. I know.
Haven’t settled on WHAT to do but we’re aware of this

If d.ToText was
ToText(formatString as text, locale as Locale = locale.Raw)
Then you could do
something.text = d.toText( “0.00” )
and you basically have “format” - quick easy and type specific

And you can make that one with a simple extends

Many of the old framework functions are simply global and we’re trying to move away from all these global functions because they all need to know far too much about everything to do their job.
Format is a perfect example.
As a global function in the framework it has to know about EVERY data type that can be passed to it.
ToText as part of the data type doesn’t. It needs to know about that one type, maybe even its bit representation in memory, and thats it.

iOS wont ever get any of the classic framework
But the new framework is unlikely to stop growing - where the classic one will
AT the moment the new framework is literally in its infancy - we have lots of things planned for it

Heres my extends for “Double” so you can write

  Dim n As Double = 1239.4567
  Dim t2 As Text = n.ToText(Xojo.Core.Locale.Current, "#,###.##") ' t = 1,239.46 
  Dim t3 As Text = n.ToText("#,###.##") ' t = 1,239.46

Public Function ToText(extends d as Double, format as text, locale as Xojo.Core.Locale = nil) as Text
return d.ToText( if(locale = nil, Xojo.Core.Locale.Current, locale), format)
End Function

This is good to know; at the moment it’s a hinderance to existing Xojo developer who’re looking to create their first iOS app.

[quote=281127:@Norman Palardy]If d.ToText was
ToText(formatString as text, locale as Locale = locale.Raw)
Then you could do
something.text = d.toText( “0.00” )
and you basically have “format” - quick easy and type specific[/quote]
Understood. The actual toText function wasn’t so bad once I looked up how to use it. The tips in the IDE show it as taking a locale only, so at first I presumed I had to create a custom locale. When I couldn’t figure out how to do that, I looked in the forum and saw how people were using it.

The thing that I found awkward was having to do the calculation separately to the conversion to text.

Dim d as double = a * b something.text = d.toText( locale.current, "0.00" )

I don’t need to keep d, so I should have to create a variable for it IMHO.

I also tried

someThing.text = double( a * b ).toText( locale.current, "0.00" )

In the end I replicated the global function “format”.

[quote=281127:@Norman Palardy]We’ve discussed changes to how things work for iOS layouts to make it less annoying since it literally solves the layout as you move controls and the constraints in place can cause others to move & … yeah it gets frustrating. I know.
Haven’t settled on WHAT to do but we’re aware of this[/quote]
This is also good to know, because it is frustrating. I was simply trying to align some controls and when dragging they showed in the correct location, but when the mouse is let go, they seem to go where ever they want.

Also when dragging the top of a control down, again while dragging it was how I wanted; the moment I let go, it reset back to the original top position, but the height was changed.

[quote=281138:@Sam Rowlands]
This is also good to know, because it is frustrating. I was simply trying to align some controls and when dragging they showed in the correct location, but when the mouse is let go, they seem to go where ever they want.

Also when dragging the top of a control down, again while dragging it was how I wanted; the moment I let go, it reset back to the original top position, but the height was changed.[/quote]

If you lock the controls as you place them and this will stop them moving all over as part of the layout being resolved

Having had to add this really makes me think we should move to how Xcode 7 does it which is to just place controls and then you add constraints - but the constraints are NOT solved in the IDE - only at runtime

In fact Xcode has split views so you can work on the layout in one & see the resolved version in the other panel but OMG it needs a TON of space !
I dont think you could use this layout style on a monitor smaller than 27"
Its barely workable on just my 24, much nicer on my 27 and almost decent if I work on the layout on the 24 and have the previews on my 27 :stuck_out_tongue:
On a laptop … HA !!!

That would be best.

The problem with only showing them at runtime is that they’re really hard to tweak unless you can visualize them in your head. I know I can do that, but not everybody can. Otherwise you get stuck in a “run-tweak-run-tweak-run-tweak” loop. IMHO that may actually be worse. I’d almost like to see a way to toggle the solver myself.

The thing is, auto layout demands some getting used to, and countless posts suggest first contact is quite unsettling.

For iOS beginners, no auto layout simulation is probably desirable, and indeed some toggling available would enable discovering what constraints do.

This method changed in 2016r2 and I thought I’ve found and updated everywhere it is used, but if I missed anything please let me know.

I have come to terms with AutoLayout and no longer have any problems with it at all. Once I’ve dragged a control into a view I never move it in the View, I only use the layout constraints to move and resize. I’m also careful about what constraints I actually use to minimize problems. There’s a learning curve but eventually it becomes second nature.