iOS For Xojo Notes #1

After doing about five hours of training video for iOS for Xojo I’ve discovered a few things.  First, the new framework will take some getting used to.  It’s not that it’s difficult to figure out, it’s just different.  Each little difference requires that I analyze what it’s doing and evaluate if I need to change my coding practices.

We’ve already talked about one of those differences with the FromText methods.  In the old framework using string.val does a lot of assumptions (not all of them good ones as we’ve come to find out) and those assumptions will either result in a valid number or a zero.  Blank strings also convert to a zero as well.

We’ve all been used to those assumptions for so long that we didn’t even realize the assumptions.  Or we ignored them.  Either way, we depended upon them.  The new framework uses much more stringent rules and if the text is outside of those rules it will throw an exception.

We can argue all day long whether it’s really an exception but that’s an argument for a different day.  Xojo has decided that errors shall not be silent (am I the only one that just said in a Gandolf voice, “Thou shall not pass (errors)!”?).  Errors causing excpetions will change the way we code and I’m still not entirely sure that I’m comfortable with those changes yet.  I’m sure it’s really a matter of getting used to them.

The other thing I’ve discovered is that events on iOS controls are different than their desktop and web counterparts.  In desktop and web if you set the value of a control it fires their relevant change events.  In iOS it does not.

In desktop and web apps we’ve actually relied upon this behavior.  Rightly or wrongly, it was there so we did.  This also meant, however, that we’ve had to somehow make a distinction of whether or not the user or the developer set the value (and caused the event).  Usually it was a matter of setting the control enabled = false while loading the data and then setting enabled = true when we were done.

Since iOS does not have this behavior I suspect we’ll start putting less code in the events of controls and instead use a method that does the work.  This is probably a good thing.  Being dependent upon the events to do something will make us better programmers in the long run (hopefully).  It’s not really a huge change but it’s a somewhat important one given the background Xojo developers have in desktop and web.

At first I thought this might be a bug but after cornering a Xojo engineer this was by design.  I can live this change now that I’m aware of it.  Do you have different thoughts on this?

What significant changes have you found in iOS that were a surprise?

17 thoughts on “iOS For Xojo Notes #1

  1. Not trying to harp on the issue, but it is changes like this that caused me to side against the new framework. Porting any desktop project larger than an example will be nearly impossible with changes such as the control event handling you speak of.

  2. Well, I see no reason to port an existing project over to the new framework. That seems to be a waste of effort. I think it reasonable to assume that new work will use the new framework.

    The fact the old framework will be around for a long time, if not forever, is a good reason NOT to port code. It’s not necessary. It’s a lot of work, and it doesn’t gain you anything concrete. Porting for the sake of porting is just silly, IMO.

    Now, I could see at some point that something in the new framework would be compelling to convert to it but since you *can* mix and match now that shouldn’t be all that bad.

    • Things are a little easier for the consultant, where such a plan is mostly possible. But consider the independent developer whose team works on a single product. They are faced with a grim reality: porting will be necessary. It is the question of “when” that is up for debate, and the question of “to what” that only the developer can answer.

      Let’s face facts. The classic framework WILL go away at some point in the future. The team can continue to use a version that supports it, but at some point that will become a no-op as well. The new framework effectively puts a shelf life on all current projects, we just don’t know what that life is.

      So does the team port to the new framework, or switch tools entirely? Only the team can decide that, but it’ll be a painful decision no matter what.

      • I don’t believe your ‘shelf life’ argument is valid. You keep talking about ‘some point’ and ‘when’. We don’t know the answer to either of those questions. The only thing we’ve been told is that the existing framework will stay for the foreseeable future.

        If the WHEN is 5 years from now (not an unreasonable timeframe IMO) the time to start porting is still not now. The framework is still new, fresh, incomplete, not to mention there will be changes as we start working with it and finding issues (e.g. FromText).

        What’s the point of worrying until we get more information and see what shakes out? If I was worried about change, I would still be using VB6. Xojo and Real Studio and REALbasic before it has been the model of consistent change over the past 15 years!

        68k to PPC to Carbon to Cocoa to ARM. Windows, Linux, Web, Console and now iOS. Three major IDE versions. C based to Xojo based. LLVM compiler. 64 bit (upcoming). Change is the only constant with this platform.

        Which is funny because most people bitch about the product not moving fast enough. Now we’re bitching that it’s changing too much and too fast. Sorry, you can’t have it both ways.

        • Bob,

          I have to wonder if Xojo Inc is not too resourced constrained to be able to keep the existing framework current with OS changes as well add few needed long requested new features AND advance the new framework at a reasonable rate. Both may wind up being compromised…

          And if that starts happening, regardless of what they want to do, the pragmatic decision on Xojo Inc’s part would be to at least deprecate the old framework and remove it sooner than later…

          Anyway that is my concern.

          – Karen

          • Lot’s of IF’s in that statement, Karen. Valid concerns to be sure but until we see proof one way or the other it’s pure worry and speculation on our part.

            You have to remember that behind the scenes they have virtually rewritten ALL targets in the past 2 to 3 years on the journey to 64 bit. We end users have found *some* regression issues but with the sheer size of the framework you figured there’d be some. Otherwise it’s been pretty quiet. Give them a bit of credit for knowing how to do cross-platform frameworks.

            Currently, there is no compelling reason to switch unless you’re doing iOS work. Somehow we’ve managed with the existing framework for over a decade and I just don’t see the switch to the new framework to happen quickly.

            Time will tell and I’m sure I’ll raise the warning flags when we start to see these concerns manifesting itself.

        • You may not be confident that the classic framework will go away, but I am. We spoke about a 10 year timeframe, which I believe is optimistic. Operating system and hardware changes, likely from Apple, will accelerate this timetable, along with more natural factors such as staff turnover. Plus, Xojo has been aggressive in shedding pieces in recent years. More than the public is aware, actually.

          My prediction, and I could be very wrong of course, is that the classic framework will be dropped sooner than Xojo originally anticipated.

          And I don’t mean to be such a persistent downer about Xojo. It’s just that in regards to this particular topic, I seriously concerned.

          • ” Plus, Xojo has been aggressive in shedding pieces in recent years. More than the public is aware, actually.”

            Well the RB3D classes, Quicktime and and Sprite surface immediately come to mind. Getting rid of the DB server was another. I guess you could say they got rid of the REALDatabase but incorporating SQLite to replace was a very good move and was a positive for us.

            Going with LLVM means getting rid of their own compiler, and that is also likely a good move and a positive for us.

            Besides not supporting 10.6 and XP any more, I can’t think of anything else.

            – Karen

          • Not supporting 10.6 is in part because of Apple and their aggressive OS release schedule. Xojo still *builds* for Windows XP even if the the IDE does not work in it.

            If memory serves, RB3D was based on QuickTime 3D. Not supported by Apple any more. Removing Quicktime was again, because of Apple, since you can’t submit to the MAS with QuickTime. In both cases Xojo had to respond to Apple’s demands or lose an entire segment of their user base. I tried using SpriteSurface at one point (many years ago) and was incredibly unsatisfied with it so it was a good pull in IMO. Yes, it sucks if you were using them but their hand was forced by Apple.

            The REALSQLDatabase server was a mistake, pure and simple, IMO. Hard to compete against free which is what MySQL and PostgreSQL are. Sure, Marco took it back over and has kept it on the market but it’s been what, almost a year, for the new version to be released? Not exactly taking the world by storm even if customers love it. Look back in these archives and I have several posts about the db server not being a good fit or Xojo (RS at the time).

            You see subtraction to the platform and I see removing distractions and obstacles to the platform.

    • Bob,

      I did not have problem with any of the items i mentioned being “discarded”… I was just trying to figure out what Thom was referring to.

      I never used RB3D nor the SpriteSurface. I also never used the server license I got with RB enterprise either. None of that going away was an issue for me.

  3. I believe Thom is correct in his assessment. They have two frameworks to support and once the new framework is entrenched and in a somewhat of a mature state, which framework do you think will receive the love and attention? Forces outside of Xojo control will force their hand where the old framework will suffer incompatibilities because it cannot keep up with the changes in the different OSes. There will be a point where a program built on the old framework will simply not be viable in the target version of the OS and that program will have to be ported to the new framework.

    What is needed is a “porting library” that will ease the pain of doing the port. The porting library would take common porting problems and do the heavy lifting to smooth out the semantical differences between the old and new frameworks. Who should create and maintain such a porting library? Maybe Xojo hosts it, but it is maintained by the community. Eventually there is going to be a lot of people porting code to the new framework and there is no go reason to keep inventing the wheel over and over for each port. A porting library would be a bridge for people to port their code without having to do whole rewrite their code base and thus give them more time to do the full rewrite if they so choose.

  4. A GREAT example of where the old framework – and VAL failed you and you cant fix it.

    VAL returns a DOUBLE – always & forever – because it is ONE method so it has to return the numeric type with the widest possible applicability.
    So how does this hurt ?
    Well a DOUBLE doesn’t have enough precision – esp if you want VAL to give you an INT 64.

    dim i64 as int64 = val(&hFFFFFFFFFF) // SHOULD give you 1099511627775 but it doesn’t = you get -1.

    With the new framework there are separate “vals” per type so you CAN have a string properly turned into an int64, integer, double, currency etc and not lose precision.

    I’m sure someone will say ”oh but you just need to …”.
    Except for one thing – the RETURN TYPE is NOT part of the signature – you cannot overload on return type only.
    So quite literally VAL does “the best it can” and it can’t ever get better.

Comments are closed.