Test Data

At XDC 2019 my session was titled Xojo Design Mistakes (the alternate but way longer title was ‘Thankfully time travel doesn’t exist or my future self might travel back and murder my younger self for the stupid coding mistakes I’ve made’).  These are things that I’ve discovered over the years, both in my own projects and in other peoples projects that are just plain wrong or less than ideal.  This will be an on-going series since I had well over 50 slides and left 150 out.  So when I get bored I’ll bring these topics up.

Nearly all of our consulting projects are database driven applications.  It’s why we’ve created the tools to help with these projects like ARGen, which simplifies our interactions with the database, and BKS Shorts, which is our own reporting tool.  These tools are invaluable in getting our work done in a timely matter.

In a database application it’s typical to have a List of something.  A common example of this is a Customers list.  In that list the client typically wants the ability to Create, Read, Update, and Delete (or CRUD) a customer with varying degrees of rules behind it (like do they have permissions to add or delete a customer?).

During development we get the List form going, add the controls to be able to add a new record.  Then we create the Add/Edit form that allows us to test those capabilities.  We create a few, update a few, delete a few customers and then move on.  Maybe the client wants search capabilities so we add that to the List window and when we’ve tested it against our half dozen or so records we move on to the next task.

There is nothing wrong with this process.  It works and it’s fairly efficient as far as it does.  However, there’s one thing we’ve skipped that’s really important but also difficult to achieve.

So far we’ve test with *maybe* a dozen records.  What happens when the client adds 10,000, or 100,000 Customer records?  Does the list form take a long time to load?  Does the search function take a long time?  What about the Customer popup menu’s that you’ve scattered throughout the project – are those now slow, unwieldy, and unusable?

Unfortunately, with the way we implemented the project we don’t know how any of this works since we only have a dozen records.  So it’s really important to have adequate amounts of test data.  Creating 10,000 new customers using your new interface would take a long time.  So what can you do?

There are tools out there that will help generate data sets.  These tools allow you to create thousands, even millions of rows of realistic data.  Randomized male and female first names along with a last names is a great way to generate customer names.  Many tools allow you to add random dates in a range, random IP addresses, random values from a  list you provide and so on.  The sky is the limit when it comes to what sort of data developers need.

Now, when you do your testing you see how your application reacts with a lot of data.  I almost guarantee that it will act different.  Do you need to switch to a data-on-demand listbox?  Do you need to put an index on a common searchable field to speed up indexing?  Do you need to implement Full Text Search in your database?  Having a huge amount of data will answer these questions for you.

I once worked on an accounting application in VB6 where the original database designer using an Access database and did an account balance on the fly iterating through bills, checks, journal entries, etc. With a few thousand rows of data in each table this process took a second or two for all balances on a local machine. When this database was accessed over the network it took 5 to 7 seconds. When we converted our first client database it took 30 to 40 seconds for EACH account! Obviously this was not acceptable performance from an accounting application meant to be used daily by general contractors with hundreds of employees and tens of thousands of customers. The solution was to have a current balance value that was stored and then updated when a transaction occurred. We could have saved ourselves hundreds of hours of rushed development time (and much stress and heartache) if we had tested with large amounts of data much earlier in the process.

I mentioned adding an Index to a field earlier. One word of caution on this: it’s tempting to add an index to every field you’re searching on. Don’t do this! Only added indexes to the most important fields in a table. For a customer maybe the two most important fields are phone number and name even though you search on City and things like that. Indexing is extra work for the database so performance can take a signifiant hit with indexing a field.

Since the toolI’ve been using to create test data is no longer being sold I’m curious what you’d recommend.  Do you have a favorite tool?  Or is this a tool that would be of use to the community?

Happy Coding!

Exception Handling

At XDC 2019 my session was titled Xojo Design Mistakes (the alternate but way longer title was ‘Thankfully time travel doesn’t exist or my future self might travel back and murder my younger self for the stupid coding mistakes I’ve made’).  These are things that I’ve discovered over the years, both in my own projects and in other peoples projects that are just plain wrong or less than ideal.  This will be an on-going series since I had well over 50 slides and left about 150 out.  So when I get bored I’ll bring these topics up.

Xojo has evolved over the years.  Many of the global framework (the classic framework) classes set an error bit or error code when an error occurred and the developer has to check to see if there is an error and deal with it accordingly.  Many developers don’t check – mainly out of ignorance, and that’s a problem.

The newer (but soon to be deprecated) Xojo framework (and we’ve been told the API 2.0 framework as well) throws Runtime Exceptions to report errors.  The exceptions definitely get your attention because, well, an exception happened.  The problem is that many Xojo developers don’t catch exceptions anywhere in their application.  This results in dialogs like this:

Users hate seeing this and it’s unhelpful to the developer because it tells them NOTHING about the cause of the error.  And, their application quits making the user really unhappy.

The Application object in every Xojo project has an UnhandledException event made to catch any exceptions not caught anywhere else.  It’s declaration is this:

By returning True you can keep the application from quitting.  Just returning true is just as bad, perhaps worse, than the first dialog because the app had an exception and the app might now be in an unknown state and the user has no idea that it happened.  At this point what happens is anyone’s guess.  Silent errors are a bad thing.  Never do this.

A better way is to use the App.UnhandledException event to report that something happened so the user can decide what to do.  Ideally, you’d like to get some information from them so the developer can get an idea of what’s caused the exception.  What were they doing when the exception happened?  What is the stack trace?

If you are are unaware of what the Stack Trace is this is the call stack your app is current in when the exception occurred.  Maybe you called the Pushbutton1.Action that called ClassA.Method1 which called Global.MethodB which called Global.MethodC.  This information (although not as neatly) is in the stack trace.  It is sometimes invaluable in helping find and fix bugs.

BKeeney Software created a generic error reporting system years ago that when put in the App.UnhandledException shows the user a dialog like this when an exception occurs.  You can tailor the message to suit your needs.

We generally don’t quit apps when exceptions are raised, but it is something that some clients want.  The Report Error button then takes them to another dialog asking for more information.  The user can easily bypass this section by pressing OK.  Hopefully your users are nice and they’ll report the error.

If they select the E-Mail Bug Report or Save Text File button without putting anything in the TextField we present a dialog begging them for more information.  Sometimes this works but not always.

Regardless, the next step in the process creates an email or text file.  Sending an email requires the use of the computers built-in email client and we find this has advantages in that we get the users email address.  A sample email goes something like this:

In our email we get the type of exception, the time, the method location, basic system information, the user description (hopefully), and the stack trace.  A vast majority of the time that’s enough to find a bug.  Sometimes it’s not but at least you can email them back.  The text file still requires them to send it to us via email so we helpfully include the support email address.

If you want to play around with this example, please download it from https://www.dropbox.com/s/3uxyqvjf4wvjrpg/Exception%20Handler%201.0.zip?dl=0.  Feel free to use in your own code however it is provided as-is with no warranty.  We cannot provide support.

You need to implement something similar to this exception handling strategy.  It will help your customers provide feedback to you so you can fix bugs.  This seems like the least you should do.  With the upcoming API 2.0 with API’s that throw exceptions rather than setting error codes this will be more important than ever.  I’m sure I’ll talk more about Exception handling strategies once API 2.0 is released.

What other types of things do you do for error reporting?

Don’t Overuse Variants

At XDC 2019 my session was titled Xojo Design Mistakes (the alternate but way longer title was ‘Thankfully time travel doesn’t exist or my future self might travel back and murder my younger self for the stupid coding mistakes I’ve made’).  These are things that I’ve discovered over the years, both in my own projects and in other peoples projects that are just plain wrong or less than ideal.  This will be an on-going series since I had well over 50 slides and left about 150 out.  So when I get bored I’ll bring these topics up.

Variants are a very powerful datatype in Xojo. It allows you do set it to anything including null. It’s a wonderful thing to use in ListBox row, column, and cell tags where the you, the developer, could be anything into it.

Variants are evil too if you use them in ways you shouldn’t. Take the example below:

This is truly a made up example but it shows how subtle Variants can stab you in the back. Just adding the three Variants together where one is a string, the other an integer, and the other a double, can change depending on the order they’re used. Frankly, I don’t care how the compiler came up with the value because in both cases it’s ‘wrong’. Wrong in the sense that it depends on order and no programmer should have to depend on order.

How did we get here? Variants have implicit conversion. So if you try to add a variant to an integer it attempts to convert it to an integer. If you try to add it to a string it converts it to a string. What happens if you have a number inside the string and it really should be a string? The answer is that it depends.

That’s just a poor use of the language, in my opinion. Xojo is a strongly typed language and I like that it won’t let me willingly add an integer to a string. I like that I have to explicitly convert from one datatype to another. Variants break that rule in that they’ll implicitly convert from one to the other and the compiler will never tell you.

The variant datatype allows the Xojo developer to query what it is. For example you can use the Type method to see what variable type is it. You can see if it’s an array using the IsArray method. You can see if it’s a Numeric value using IsNumeric but you get into the same problem where assigning an integer 8 and a string “8” will both return true from IsNumeric. So it’s a bit of a problem because it could be either. We should rename it Schrödinger’s datatype because it could either either value until the compiler asks for it.

Auto was introduced in the Xojo framework (deprecated now?) to replace Variant. It didn’t do any implicit conversion for you. In fact, it wouldn’t even tell you what datatype was in it and the only way to do was to use Introspection. It certainly solved the problem of implicit data conversion but replaced it with a harder to use datatype. For what it’s worth I didn’t think it was hard to come up with your own “what is your type” methods using the extends keyword but it was something that many Xojo developers weren’t comfortable doing and frankly seemed silly to rely on Introspection to do that work.

I turned down a project many years ago because the original developer had used Variants for everything. Didn’t matter what (local, object, global), they used variants and they wanted me to tell them why their project wasn’t working right. When I told them I wouldn’t do it and asked why they had used variants for everything they simply said, “Because they could be anything. Why not use them?”

I know that many languages are not as strictly typed as Xojo and perhaps that’s where they came up with that mentality. I find some comfort in knowing that if I try to put a string into a numeric value the compiler won’t let me unless I explicitly convert it. I like the certainty of knowing that my data can’t change on my unless I tell it too.

Variants are good for storing things temporarily. Stashing values and objects in a Tag for use later is convenient and useful and a good use for them. For everything else it makes sense to use a datatype. If you finding yourself using a lot variants you should rethink what you’re doing because they can subtly make your calculations change in ways you don’t expect.

Don’t Use GoTo

At XDC 2019 my session was titled Xojo Design Mistakes (the alternate but way longer title was ‘Thankfully time travel doesn’t exist or my future self might travel back and murder my younger self for the stupid coding mistakes I’ve made’).  These are things that I’ve discovered over the years, both in my own projects and in other peoples projects that are just plain wrong or less than ideal.  This will be an on-going series since I had well over 50 slides and left about 150 out.  So when I get bored I’ll bring these topics up.

Don’t use GoTo – ever.  GoTo is a holdover from the old BASIC days where code was unstructured and you needed to manage flow-of-control.  Old BASIC programs used a ton of GoTo statements because, well, you just had to.  It was the only way to get anything done.  Xojo uses a modern BASIC syntax but it’s fully object-oriented code and still has GoTo as a reserved keyword and it still functions.

Xojo has many ways of doing flow control.  There are multiple ways of doing loops with While’s, Do-Loop’s, For-Next’s, and we control those loops with keywords such as Continue, Exit, Return.  Since we have methods and functions too we can exit those by calling Return at any point in the method and the code resumes execution at that point.  GoTo just isn’t needed any more.

And yet GoTo still exists.  I recently ran across this code in a project we’re updating for a client.

As you can see we are in a fairly typical For-Next loop iterating through a ListBox.  The first line into the loop we check if we’re closing the window and if we are we call GoTo bale which takes us to where bail: is.  Bail is at the bottom of the method and we’re doing nothing afterwards (the last two lines are Exception handling in this method and aren’t called).

This is such a poor example of Xojo coding.  We can use Exit to accomplish the same thing since Exit will immediately exit the loop and since there would be nothing after the loop it would simply leave the method entirely by simply calling Return.  There’s no penalty for using either Exit or Return.

Honestly, I have no idea why the original developer did this.  I think they came from VB6 where code like this was pretty common, but even in that language there were much better ways to do the same thing.  So I will call this lazy coding because the developer didn’t use the best way in Xojo.

Using GoTo like this is potentially risky too.  Feedback case 24710 shows that using GoTo may cause a memory leak because the compiler may skip cleanup code.  I think the above code is safe but I could see if we loaded oNote before the GoTo exiting the loop it would be dangerous.  But even still, if GoTo is outdated, not recommend, and dangerous on top of all that why use it?  I can think of at least three ways to make this code safer and better.

At the end of the day, If you’re using GoTo – don’t.  Refactor your code so it makes use of the modern Xojo calls. It’s safer and the right way to code in Xojo.  Your future self will thank you.

(233)

XDC 2019 Ruminations

The 2019 Xojo Developers Conference (XDC) wrapped up last Friday. It’s my favorite event of the year and while I’m sure many people think that I’m an extrovert I can only play one for shorts periods of time. I’m enjoying the peace, and more importantly, the quiet at home today hoping to recharge my social battery before having to attending a high school robotics meeting, mandolin orchestra rehearsal, and a mandolin concert this week. Oh, and I have to pick my sone up in Chicago. No pressure to get things done, no?

XDC is my favorite time of the year. While attendance was down this year (more on this in a bit) a lot of people from Europe made the trip over to Miami. It was good to see a lot of old friends and awesome to make some new ones. To me, it’s the connections you make and the stories you hear from other Xojo developers that is inspiring in so many ways.

The keynote address by Geoff was…underwhelming. It was the usual mix of how the community is doing, what they’ve done since last XDC and what they’re working on. As expected they’re working on Web 2.0, API 2.0, Interops, and Android. The best timeframe Geoff gave for anything was ‘soon’. At least we didn’t have the mental gyrations over ‘priority’ and ‘important’ like last years XDC.

It’s hard to show much for big ticket items like Web 2.0 and Android. These are big multi-year projects that you just can’t show off without having significant work done on them. For Web 2.0 the demo that Greg gave seemed pretty solid but then there weren’t a lot of details. It did seem solid and that was good news in my opinion. The Android demo, on the other hand, looked much more scripted and not nearly as smooth – it had the feel of ‘this is something we know works and we’re not going to do much outside the script’ feel to it. For API 2.0 there wasn’t much to show except some before and after code snippets.

So on one hand the keynote wasn’t all that exciting. On the other they didn’t have much to show because it’s work in progress. They threw some numbers out like 70% complete in which the pessimist in me said, “great, that means there’s still 70% of the work left to be done.” The people around me at the keynote had some similar thoughts as mine. To be fair, ‘completion percentage’ means something different to everyone.

I am very excited about Web 2.0. It’s a rewrite of the entire framework. You have to keep in mind the original framework was done ten years ago and the web has changed drastically since then. The work they’ve done on theming is going to make our Xojo web apps look fantastic and since more processing is done on the client side it should make apps a lot more responsive. We’ll have a LOT more controls to play with too.

To be honest, I’m pessimistic about Android. I’m sorry, but two years later we’re still waiting for a release. With work still to be done on the Xojo framework items (think FolderItem) and the debugger I just don’t see that happening by the end of the year. Prove me wrong, Xojo.

Jim Meyer’s presentation on using AWS and Google Machine Learning API’s with Xojo was fascinating. Using their API’s it’s easy to do text transcription from text and video, recognize images, do facial recognition and much more. It was by far my favorite session I attended. I can’t wait to get the example projects and try them out on a few things.

I didn’t attend this session but attendees were buzzing about Monkeybread Software’s DynaPDF plugin. The big news was that Unicode support will be added by the end of the year and that we’ll be able to create PDF’s by drawing directly into the Graphics object provided by the DynaPDF class. All good news.

Michael Dettmer showed an interesting way to quickly create database applications for Xojo using an Apache Velocity and his own open source software called CAPP, or Computer Aided Program Production. Essentially you create templates for the various things you want and it creates a project for you. The drawback is you have to use Apache Velocity and Java to do some of the coding. I’m not doing the demo justice but it did look a bit more complex than many Xojo developers might be capable of. However, consultants might find this tool essential since you do a little work up front to create a database application. You can read more at https://capp.systems

Yousaf Shah had a great session on how to get happy customers, successful projects, and live stress free. Yousaf said that developers aren’t always the most empathetic people and it’s hard to put yourself in the client position. When mistakes are made you don’t have to admit a mistake but saying, “I’m sorry you feel that way,” is important. He also spent some time showing how we can go from features to tasks (wrong word) so that you can get a better feeling for what the client really wants while also letting them be in control driving what’s important to them.

One session that I thought was fairly depressing was the Ask the Engineers session. Greg, Travis, William, and Paul did a good job of answering questions from the audience but it was shocking to see that few of developers working on the product. They’re one heart attack away from major portions of the project to be delayed. If you didn’t know, Paul has been moved from his Evangelist role to an engineering role. Since last XDC Norman was let go and Joe (compiler) has moved on to another job. Geoff can say all day long that they have enough resources but I just don’t buy it. More engineers means more stuff gets done.

Not giving us any timeframe for releases is one reason why I think attendance was down this year. If you don’t think there will be any big news and hands-on with cool, new, stuff then what’s the point of the attending? I disagree with the reasoning but I understand it when it’s a significant cost to attend.

No XDC in the United States next year. They are looking at something overseas. No word on where they’re looking but since MBS has conferences in Germany that are well attended I suspect some place other than Germany. But who knows? Like everything else they’ll tell us when they tell us and BKeeney Software will most likely be there. After all, it wouldn’t be a Xojo Developer Conference with us being there! See what whenever and wherever the next one is held.

Thoughts on XDC 2019?

XDC 2019 – API 2.0

At XDC 2019 Paul Lefebvre and Travis Hill did a session on API 2.0.  For those not familiar with API 2.0 it’s the result of the best parts of the Xojo Framework getting merged back into the global framework without the heavy use of the Text and Auto datatypes.

The first version of Xojo (AKA REALbasic) was in 1998.  Supported Mac 8.  Now in 2019 MacOS, Linux, Windows, iOS, Web, Raspberry Pi and soon to be Android.

The goals of API 2.0:

Utilities language improvements.  In 1998 no shared methods and other features available now.

Improve Consistency.  Naming was often based on specific OS things that don’t exist before.  

Better Naming.  

Exceptions, not Error Codes.  Error codes get ignored – Exceptions are now.

Fewer Globals.

More Enumerations.  Constants lead to enforcement issues.

Similar API for Controls

But overall, don’t want to change what works.  The global framework has worked great for many years.

Progress Update:

Large portion of API 2.0 will be rolled out soon.  “All” from Geoff’s keynote may not be accurate

When it happens they’ll be deprecated – NOT removed.  It’ll be there for many many years.

Stop using in documentation and code examples.

API 2.0 Benefits

Code is more readable.

Easier for new users to learn.  Most consistent for existing users.

Easier for all when working across project types.

Notable New Features

URLConnection.  New in 2018 R4.  Added Synchronous to the Asynchronous option.  Uses OS API’s.

Var and ResizeTo.  Synonyms for Dim and Redim.  Var is better term and used in other languages.  

Notable Changes

Databases

Exception Handling.  No longer uses error checking.  Works on Connect, ExcecuteSQL, SelectSQL.  

DatabaseField -> DatabaseColumn

DatabaseRecord ->DatabaseRow

Recordset -> RowSet

BeginTransaction

Binding is now embedded in the SelectSQL.  Infers the BindType from the DataType.  

FolderItem

Uses Exceptions

Open methods moved to more appropriate classes (OpenAsMovie, OpenAsSound, OpenAsVector)

Item -> Child

Listbox

ListCount -> RowCount

ListINdex -> SelectedIndex

Cell -> CellValueAt

DeleteAllRows -> RemoveAllRows

RemoveRow -> RemoveRowAt

ColumnFromXY -> ColumnAtPoint

Header -> HeaderAt

Other

ToString/FromString on Date and numeric types

String.BeginsWith, EndWith, IndexOf.  All methods will be zero based.

Timer.CallLater, Tolerance

Date intervals and time zones

Random is now a singleton class.

Point, Size, Rect no longer need the “Realbasic” prefix.

Desktop is first.  Then Web 2.0 and then mobile (first with Android then iOS).

You’ll be able to change code at your own pace.  None of the existing methods are going away.

This is a one way move.  The goal is to let older versions of the IDE still *open* API 2.0 projects.  Obviously you’ll get compile errors then.

Will deprecated stuff will not show in AutoComplete.  It’s doubtful if it will improve AutoComplete performance.

XDC 2019: Web Framework 2.0

At XDC 2019 Greg O’Lone of Xojo showed us the current status of Web Framework 2.0.

The design goals for the web framework:

Update the server technologies.

Improve responsiveness

Modernize the framework

New and Updated Controls

Improved Browser Support

HTTP 1.1 compliant server.

Minified frameworks and Client Rendering (more done on the browser now)

jQuery – feature rich JavaScript library

Boostrap and FuelUX controls

Browsers:

Support as many of the current browsers as possible.  Current framework parses headers to determine what to support but most browsers lie.  Going to ask the browser what it supports.  The controls themselves will determine what they can do.  Things like TouchEvents and File API support might change.

Adding Browser History triggers.  Can tell the session that something happened.  For example if user was filling out form partially and hit back button.  When they come back to the site the HashTagChanged event fires can allow you to get that information back

Visual Session Controls.

Server Connection Monitor.  New dialog to show user that it’s having problems communicating.

Layout Modes:  Fixed, put a control on a layout and it just stays there.  Fluid layout lets controls flow around in the container.  Auto(layout) – not in version 1.

Big list of already supported controls.  New ones:  MessageDialog, PagePanel, Breadcrumb, Rich Text Editor.

Big functionality updates:  File Uploader (splitting engine from the interface).  Listbox has pagination, dynamic data sources, sortable columns, built-in filtering, custom column types.  Canvas has layers, events, and Drag and Drop on browser side.  Toolbar is Bootstrap (but will have icons) and it will act more like the desktop toolbar.  TextFields gets browser side text formatting and validation.  MenuItems are theme compliant, disabled items, hierarchical, separators, and headers.

Styles:  Existing editor is painful.  All projects will get the global Bootstrap theme.  Drop-in theme replacement.  Themes can be previewed in the IDE!!!  Selective control-level customization more like what we get on the desktop.  Property-level style access which means will be able to change styles via code!

Project transition is a one way operation.  Using API 2.0 but will still use the deprecated API.  Some things like ListBox.AddRow will automatically converted to new API.  CGI projects are going away and the only option will be standalone.

Xojo Cloud will be using only 64-bit standalone apps.  You’ll get Load balancing and multiple domain names.  Must be using the newer server configurations.

WebSDK 2.0:  jQuery, Bootstrap and FuelUX will be included.  Browser feature detection and we’ll be able to query to see if a browser can do something.  

TypeScript allows us to compile the Javascript that all browsers use.  Get some definition files and other things.

Greg shows us a demo of the Web Framework 2.0:

Shows a WebPage that has working TabPanel.  Layout Editor drag and drop not working quite like it will in release version.  Shows me MessageDialog.  Shows new ChartingControl.

He then shows us changing the theme.  Simple drag and drop of Cyborg theme changed everything in the project.  Very nifty.

Greg shows us pre-Alpha Feedback using Web Framework 2.0.  TextField support password managers now!   Buttons are Escape and Enter sensitive now.  Listbox has custom column types:  Picture column and URL column.  Clicked on a link (Feedback report) and then opened it.  Showed use of the back button that took us to previous action.  Then showed Dynamically Load listbox an dhow it loaded more data as he scrolled to the bottom of the list.

Very functional demo!

Q & A:

Message Dialogs have icons?  Yes, just like current desktop.

The demo showed 3 buttons.  Will it return values?  Yes, just like current desktop.

Will container control will be draggable?  Redesigning drag and drop.  So maybe?  Might not be right away.

Pushing more stuff down to the client will be have access to hardware/devices on client side?  You’d have to use Internet Explorer and the WebSDK to load and ActiveX control.

How easy to support Dark Mode in web apps?  Only supported in Safari.  Answer is maybe and change the stylesheet on the fly.

Recommend load balancer for new web framework?  No.  Used it with several load balancers and they all worked.  Changed how much data is being transferred between client and server.  Transmissions cut down by 60%.

Can users change theme at runtime?  Yes.  Maybe not in version 1.

With Xojo Cloud load balancing is there any scheduling or rules?  Control distribution is up front – no thoughts on scheduling.

With new Canvas control would you be able to create a game with it?  Their intention is to expose the canvas handle to developers.  Some restrictions.

Custom skinning on progress wheels?  Yes.  Current one is SVG and it just rotates it.

How will editing in web listbox work?  Custom column type.  Doesn’t work today but a huge want.

Listbox has a built-in Search Field.  ListBox in general has a number of things built-in.  By Default has pagination and search field.  Will eventually support multiple layout types (list, picture) but not for version 1.

Open events work by the way.

Will tags be available in more places?  We haven’t done that yet.  Unknown if it will get into version 1.

User get click happy is there a way to prevent weird stuff from happening?  Still have the Auto Disable for buttons.  There is some mechanism in place to prevent the exact same event from being sent to server.

Column sorting and pagination?  Adopted desktop behavior for column sorting.  Sorting a column will requery the database.  Always goes back to the data source.

XDC 2019: Android Walkthrough

During the Android Walkthrough session at XDC Travis Hill and Paul Lefebvre showed us the current status of making Android apps via Xojo.  As Geoff said in his keynote there is considerable amount of work left to be done.

Last XDC had some compiled code running in the emulator and one control.  That was it.  

Today they have compiled code running in emulator and devices for both 32-bit and 64-bit.  APK creation.  Emulator installation and execution.  Control positioning and locking.  Now has 25 controls which is a bulk of the controls for version 1.

Buttons:  Regular, Segments, and Toolbar

Pickers:  DateChooser, Slider, Switch

Inputs:  TextField and TextArea

Decorations:  Label, canvas, oval, rectangle, and separator

Organizers:  TabPanel

Indicators:  ProgressBar, ProgressWheel

Viewers:  HTMLViewer, ImageViewer, ScrollableArea, Table, VideoViewer

NonVisual:  ImageChooser, Location, MessageBox, Timer

Tech Details:

Android is unique.  Code that executes via Java Virtual Machine and Native.  They communicate via the Java Native Interface.  The Xojo framework is built with Xojo and Kotlin.  Kotlin is recommend by Google.  But essentially we don’t have to worry about.

Application execution works with both 32-bit and 64-bit.  32-bit OS is still popular on devices.  Support ARM (devices) and x86 (emulator).  Xojo figures it out for you automatically.

Typical data types:  Integer, Double, String, Variants.

Layout editor is what we’re familiar with.  An Android ‘view’ is really just a Window.  

Uses API 2.0.   Which means Standardized naming.  Errors are exceptions.  Zero based offsets.

Requirements:  Mac/Windows 64-bit for the first version.  Linux has some unique issues.  Android Studio required to provide the emulator and debugging tools.  Android 9.0 (Pie) SDK.  Target Android 4.4 and better.  Will run on a vast majority of devices in the world.  SDK version can change.

What’s Left?  Largest piece left is Framework completion.  The other big piece is the Debugger – there are some technical challenges in debugging with the native and JVN code.  

So, no answer to when it will be available.

The Future:  After initial release Auto Layout (used control locking to begin with).  Will eventually support plugins (those built in Xojo) and those can call OS API’s (JVM) and/or include native libraries.  Most of the focus on phones and should work on tablets.

Travis showed us a demo of Android:

Layout Editor looks very much like iOS – except it looks like Android.  Drag and Drop and resizing the Layout Editor looks pretty smooth but nothing that iOS doesn’t already do.

Hitting Run for a simple app didn’t take too long and it opened it in the emulator.

Travis mentioned that even with debugging you have to do Code Signing.

In 2nd example he showed an Android table with some initial values.  Table scrolled properly.    He flipped the phone in the emulator and showed that the control didn’t adjust.  Went back and used the Lock control properties in the inspector and then took it back into emulator to see it in action.

Q & A:  

No container container in list.  Yes, there will be.

Can you write an iOS and Android from same project?  No.  Not today.

Currently it builds 32-bit and 64-bit builds automatically.

Why do plugins need to be in new format?  The plugin format allows you to call the JVM and native libraries.

API 2.0 is changing the offset of strings?  Some confusion on what that will mean.

Using constants in the app, can it be decompiled and be seen?  Important strings should be obfuscated.

XDC 2019 Keynote

The annual Xojo Developer Conference (XDC) kicked off in Miami, Florida.  Geoff Perlman, CEO and founder of Xojo  took to the stage to welcome conference attendees and give us an update on Xojo.

Attendees:  

15% new to the conference.  40% outside of the United States.  11 different country.

Community:

New users up over 200% (this is web site and  account creation).

Special recognition for Hal Gumbert and Tim Dietrich for evangelizing Xojo on Twitter and social media.

Thomas Tempelmann was also recognized for his efforts to get Xojo recognized on Slant

Demographics:

2017:  half of all users under 35.  20% were women

2019:  60% of all user under 25.  40% are women

Forum:  over 19,000 members,  Over 47,000 conversations.  Over 400,000 posts.  Currently use EsoTalk and they are working to move to Flarum (flarum.org).  All of the content will be converted over so nothing will be lost.

Xojo Design Awards:

Consumer:  Goldfish for designing we applications.

iOS:  snow Maps by Jérémie Leroy.

Education:  AcaStat – AcaStat Software

Vertical Market:  Script Studio – Nuvotech Limited

Cross-Platform:  Studiometry – Orange Software

Developer Tool:  Graffiti Suite – Graffitti Suite

Honorable Mention:  Mike Cotrone, developing app and was asking how to structure the database to track chicken and egg tracking application.

Last 12 Months:

48 features

75 changes

465 bug fixes

New stuff:

Dark mode caused issues with schedule.  Turned out to be non-trivial.  Took an entire release cycle.  

iOS Table

Native labels in Windows

Better text rendering in Windows

API 2.0 – URLConnection

Incremental compilation for 64-bit and ARM

IDE faster Layout Editor

The Path Forward

Xojo Cloud:  

64-Bit

Named Hosts

Stand Alone Apps

Load Balancing

Interops:

Less complicated way to call into the OS.  No conversion of data between OS and Xojo data types.  The XDC iOS app is using Interops.  Geoff showed an example of old declares and the same thing with new Interops.  Interops AutoComplete and are available in the Inspector.  Using it to build the Android framework.

Plugins:

Development is paused for now to get Android out.

IDE Update:

Idea is to improve the user experience.  2019 R1 had improvements to the Layout Editor.  Navigator is going to change.  It can work with or without tabs but essentially the Navigator is becoming the Home listing and once you double click it dives into that object.

Coming soon.

API 2.0

URLConnection is out and improved.  Bezier Curves is coming.  FolderItem for MacOS is getting revamped and the API’s from Apple are deprecated.  Better speed.  New Date class is getting many of the features that Xojo framework Date class has.

Most API’s not changing.  That that are replaced will remain for many years.  You don’t have to rewrite code right away.  Analyze Project will tell you what you’re using that is deprecated.  Replaced API’s will no longer auto-complete.  Documentation pages will no longer list the replaced API’s.

Rolling it out in one release.  

Web Framework 2.0:

Current web framework was released in 2009.  A lot has changed in web technologies.  With Web 2.0 it was a ground up rewrite.  Significant optimizations.  Far great speed between client and server.  Overhauling 6 controls.  13 new controls.  Greatly improved style management.  Improved the look and feel.

To test they ported Feedback to Web 2.0.  Greg will be showing it in his session.  Long term goal is to replace the desktop version of Feedback with a web version.

Android:

Last year they showed a simple Hello World application.  Very cobbled together.  Now they’ve got IDE integration, running in the Android simulator.  Run on actual hardware.  Building is now working.

XDC app is now available for Android.  It’s available in the Google Play store.  The caveat is that it’s really just an HTML viewer so obviously there’s a lot of work left.

Hard parts are done.  What’s left is implementing the Xojo framework.  Porting the Debugger is also another big step.

One Last Thing….

Geoff promotes the MBS European Conference in Cologne, Germany.

That it!

XDC 2019 Is Almost Here!

The Xojo Developers Conference (XDC) is just around the corner.  In less than two weeks Xojo developers from around the world will gather in Miami to talk Xojo for three full days.  The speakers have sent in their slides and gotten feedback from Xojo and flight and hotel reservations made.

This is my favorite part of the year!  Really.  BKeeney Software has been around for nearly 18 years and in that time I’ve gone to many Xojo Developers Conferences including those sponsored by Xojo, sponsored by Monkeybread Software, and even held a few I helped host with the defunct Xojo developers user group.  

Many of the developers that attend are my friends.  Many more are colleagues, and competitors.  Some are current and old clients.  Some of those clients I met at XDC looking for developers for their project since there will be no greater concentration of Xojo developers on the planet!

You’d think that with as many developers conferences under my belt there would be nothing new to learn.  I disagree since Xojo is always morphing into the next phase of its existence.  When I started, 68k Mac apps were transitioning to PowerPC.  They added Windows and Linux targets.  They added Cocoa for MacOS, 64-bit builds for Mac, Windows, and Linux, the ability to create web applications, Raspberry Pi apps, and mobile applications for iOS.  

I expect this year we’ll learn a lot more about Xojo for Android which will be a significant new target and make iOS that much more relevant with Xojo.  We’ll learn about InterOps that aims to make adding libraries much easier for iOS, MacOS, and Android.  And I’m sure we’ll see a lot about Web 2.0 that will make Xojo web applications more powerful and more robust.

At the end of the week, it’s always sad to go home.  The bonds you make while sitting across the table from someone at a meal, or over drinks at the end of the day, is something that you can’t get in the forums, email, or via videos from the conference.  Don’t get me wrong, the Xojo forum is one of the friendliest developers places I’ve ever experienced, but there is something truly powerful about chatting with people and being able to read their body language and talk about their developer experiences that far outweighs the convenience of the electronic venues.

If you have the means I highly recommend making it to XDC.  It’s well worth it.  You’ll get to meet some awesome people, learn a bunch of new things, probably see some alpha or beta of new features, and overall have a good time with your extended Xojo family.

If you’re going and we haven’t formally met, please feel free to stop me and introduce yourself.  Remind me how you came to find me and what products, if any, you use.  Tell me what features you like, or don’t like.  Just say hi and then go talk to the many other Xojo developers there – you might just find friends for life.

Of course I’ll blog about the keynote and the cool new things that I see at the conference.  See you in Miami!