Google just released AIDE, their Android Java IDE. It's probably a good idea that they provide a development tool rather than rely on tools they don't control. Most platform vendors provide tools. What's different about AIDE is that it's designed to run on Android itself.
This means you can develop Android apps on an Android tablet or smartphone. This sounds really intriguing at first until you start imagining what this might really be like. A tablet might make some sense, but as someone who developed software on a Mac with a 9 inch screen, it's not ideal. Yes, today's tablets have a higher resolution than my circa 1985 Mac, so there are more pixels in a 9 inch tablet screen. Still, developers generally want as much screen real estate as they can get. The minimum screen size for developers here at Real Software is 27 inches and some have multiple monitors. I would expect the many Real Studio users would be similarly configured. A 9 inch tablet screen doesn't seem like a very productive environment for developing an application. The only thing worse that I can think of would be attempting to develop software on a 4 inch smartphone screen. Oh, wait. That's exactly what Google is suggesting. The screenshots and demo videos seem to focus more on using a smartphone than on the tablet.
I can see the novelty of this but it doesn't seem at all practical. Just because you can create an IDE that runs on a 4 inch screen doesn't mean you should. Also compiling, even to Java byte code, is processor-intensive which I'd expect is going to drain the battery faster than a lot of other activities. Developing also involves a lot of typing. The touch-based keyboards on smartphones and tablets work fine for the kind of work that is typically done on those devices. But development usually involves typing a lot of code and a full-sized, tactile keyboard is really required for reasonable productivity.
The user reviews on the site are all quite positive which surprises me. Perhaps they are just caught up in the novelty of it and haven't considered the productivity issue.
Seems like AIDE should be designed primarily to run on a PC but perhaps include a version that runs on Android so that developers can get to their projects from anywhere. This would likely require Google to have a sync system like Apple's iCloud and Google certainly has the infrastructure to easily provide it. Heck, the projects could just be another type of Google Document.
Is it just me? What are your thoughts?
Friday, March 16, 2012
Wednesday, March 14, 2012
The Best of SXSW Startups
SXSW Interactive has been dubbed the “innovations fair” of tech startups. Looking back on the trend of companies that had their big break in the heart of Texas during SXSW, it doesn’t look like it’s slowing down anytime soon. With influencers growing by the thousands and flocking to our hometown of Austin, it’s only safe it wonder who we are going to see emerge as the new-found talent this year. Mashable recently wrote a piece on three apps that they believe will find their fame this year. Any apps out there that have caught your attention?
Wednesday, March 7, 2012
Minimum OS X version for Cocoa Support
When considering what will be the oldest version of any operating system we can effectively support, there are two considerations: the number of users of that version and the cost for us to support it. When the number of users is small but the cost is large, obviously it probably doesn't make sense to support it. This is the case we have run into with OS X 10.5.
Looking at the numbers, OS X users essentially fall into two camps: those using 10.5 (Leopard) and below and those using 10.6 (Snow Leopard) and above. According to the data we have gathered, over 80% of OS X users are using 10.6 or 10.7. While that does mean that almost 20% of OS X users are still using Leopard or earlier, that number is dropping.
Next, let's look at cost. Because of improvements in 10.6, supporting 10.5 and earlier often doubles the amount of effort for us because we have to code things one way for 10.5 (and earlier) and another way for 10.6 (and later). This means we fix fewer bugs and spend more time and energy on new features than would otherwise be unnecessary. Supporting 10.5 would make it impossible for us to use some of the new features of OS X 10.7 (Lion) as well. So the cost of 10.5 support is pretty high.
Because of these two factors, we have decided that the minimum OS X version we will support for Cocoa starting with Real Studio 2012 release 1 will be OS X 10.6 (Snow Leopard). Because Real Studio 2012 Release 1 will also be a Cocoa application, the minimum version to run the IDE will also be 10.6.
If you need to support users with 10.5 and earlier, you can continue to compile a Carbon version for those users. Projects saved in 2012 R1 will open in 2011 R3 which means you could even compile for Carbon on PowerPC if necessary. However, in this case, do NOT save your project in 2011 R3 once you have saved it in 2012 R1 as you may lose data. Just use 2011 R3 for compiling to PowerPC.
We don't make decisions like this easily or lightly. But they must be made in order for Real Studio to continue to move forward.
Looking at the numbers, OS X users essentially fall into two camps: those using 10.5 (Leopard) and below and those using 10.6 (Snow Leopard) and above. According to the data we have gathered, over 80% of OS X users are using 10.6 or 10.7. While that does mean that almost 20% of OS X users are still using Leopard or earlier, that number is dropping.
Next, let's look at cost. Because of improvements in 10.6, supporting 10.5 and earlier often doubles the amount of effort for us because we have to code things one way for 10.5 (and earlier) and another way for 10.6 (and later). This means we fix fewer bugs and spend more time and energy on new features than would otherwise be unnecessary. Supporting 10.5 would make it impossible for us to use some of the new features of OS X 10.7 (Lion) as well. So the cost of 10.5 support is pretty high.
Because of these two factors, we have decided that the minimum OS X version we will support for Cocoa starting with Real Studio 2012 release 1 will be OS X 10.6 (Snow Leopard). Because Real Studio 2012 Release 1 will also be a Cocoa application, the minimum version to run the IDE will also be 10.6.
If you need to support users with 10.5 and earlier, you can continue to compile a Carbon version for those users. Projects saved in 2012 R1 will open in 2011 R3 which means you could even compile for Carbon on PowerPC if necessary. However, in this case, do NOT save your project in 2011 R3 once you have saved it in 2012 R1 as you may lose data. Just use 2011 R3 for compiling to PowerPC.
We don't make decisions like this easily or lightly. But they must be made in order for Real Studio to continue to move forward.
Monday, March 5, 2012
Creating Installers for your Desktop Applications
From time to time, I see people on the forums and mailing list ask about ways to create installers for their Real Studio desktop applications. I'm going to cover some of the tools I have used which have worked well.
Mac OS X
The simplest thing to do on Mac OS X is to distribute your application as a zip file. Your user can then unzip it and drag it to the Applications folder.
This might seem too simplistic for you, so another option is to distribute your app using a DMG (Disk Image) file. The user double-clicks this file to mount it in the Finder and then drags your application to the Applications folder. If you use a tool, such as DMG Canvas, you can also add a background (and Applications alias) to the DMG to make it easier for your users.
The final option is to use an installer. Even if installers are somewhat uncommon on Mac OS X, they can still be useful. You may find your users are more comfortable running an installer even it it doesn't do anything more than copy your app to the Applications folder. And an installer can make it easier to copy files to other locations and prompt for authorization.
Apple includes a tool called PackageMaker for free with their Xcode developer tools, but I've found it difficult to use and a bit crashy. So I use Iceberg instead. Iceberg is a free tool to create installer packages. I've used it on most of my projects for several years now and it works great.
Keep in mind that you'll still need to deliver your installer as either a zip or on a DMG.
Keep in mind that you'll still need to deliver your installer as either a zip or on a DMG.
Windows
Windows users expect an installer, so you can't really get away with just using a ZIP file. Depending on the project, I've used two installers on Windows: InnoSetup and Advanced Installer.
InnoSetup creates setup.exe installers and is pretty easy to use once you get it set up. Unfortunately, you do have to create your script by hand. There is an example script in the documentation wiki to get you started.
Advanced Installer has a full-blown UI and is quite easy to use. The free version will likely suffice for most of you, but they also have a more powerful paid version ($300). In addition to the nice UI, Advanced Installer can create MSI (Microsoft Installer) files, which are preferred by IT departments. From what I understand, an MSI makes it easier to do remote and bulk deployments.
There are plenty of other installers for Windows, including the popular and expensive InstallShield tools. But I think that Real Studio packages up your application so nicely that you are not likely to need all the capabilities that the more sophisticated tools provide.
Linux
Often I don't bother with an installer for Linux, figuring that if the user is sophisticated enough to be using Linux, they probably don't need an installer. But I had a client that really wanted an installer for their customers. After some research, I found a nice little tool called InstallJammer. It is free (open-source), but unfortunately looks like it is no longer being updated. It's still worth looking at, though.
Thursday, March 1, 2012
Documentation Changes
You may not be aware but the Real Software Documentation Wiki has had quite a few updates recently.
First, the main page has been redesigned to better organize the sections of the Documentation. The Language Reference is at the top, Desktop and Web Applications share the center and General Information is at the bottom.
The Web Applications section has three new articles about hosting your web applications:
In order to improve searching, more redirects have been added to the wiki for common search terms. For example, try searching for "control arrays" or "attribute editor".
The Language Reference has also been updated quite a bit. View the Recent Changes page to see all the changes. These Language Reference changes will be available in the local Language Reference when Real Studio 2012r1 ships.
I hope these changes make our Documentation Wiki easier to use and more useful.
Thursday, February 23, 2012
Some useful Pragma commands
The Real Studio mailing lists are always a source of lively discussions. A recent thread started with a suggestion to allow commented code to retain its formatting for readability. This brought up a long discussion about ways to disable code.
Disabling Code
Like many of you, when I need to disable a block of code I'm working on, I will select it in the code editor and then click the Comment button on the toolbar (or press Command-'). This loses the code formatting structure (indentation), which I never really considered an issue.
It turns out there is already a way to disable code and keep your formatting: use conditional compilation.
Although you may never have done it in this manner, code like this will disable everything within the #If/#Endif:
#If False Then
Anything can go here, whether it is code or plain text.
Dim count As String
For i As Integer = 1 To 100
count = count + Str(i)
Next
#Endif
#If commands are parsed before the compiler does its magic. Since #If False is never true, these commands are stripped from your code before being sent to the compiler.
Of course, it is less convenient to disable code this way because you actually have to type in the commands. A contextual "Wrap this" menu might be useful here. I created a Feedback case for this: 20397
Errors and Warnings
The discussion brought up a couple other useful Pragmas: Warning and Error. To be perfectly honest, I never noticed that these pragmas even existed! It turns out they were added years ago (Real Studio 2008, according to the Language Reference).
Something that I do often is mark code that I need to go back to for some reason. Typically, I add a comment at the top and put TODO in it with a description:
// TODO: Fix this nasty hack
I think that usage stems from my Visual Studio days. I would then periodically search the project for TODO and would have a list of things I need to address.
It turns out you can get even better behavior using #Pragma Warning:
#Pragma Warning "Update this code to use Menu.Clone."
Dim selectedMenu As MenuItem
selectedMenu = EditMenu.PopUp
Your project runs just fine, but when you Analyze Project (or Item), this warning is displayed in the Warnings List. I really like this and will start making more use of it.
The related Error pragma generates a compile error:
#Pragma Error "Stopped the compile."
I haven't thought of a good use for this yet, but I'm sure someone can enlighten me!
Disabling Code
Like many of you, when I need to disable a block of code I'm working on, I will select it in the code editor and then click the Comment button on the toolbar (or press Command-'). This loses the code formatting structure (indentation), which I never really considered an issue.
It turns out there is already a way to disable code and keep your formatting: use conditional compilation.
Although you may never have done it in this manner, code like this will disable everything within the #If/#Endif:
#If False Then
Anything can go here, whether it is code or plain text.
Dim count As String
For i As Integer = 1 To 100
count = count + Str(i)
Next
#Endif
#If commands are parsed before the compiler does its magic. Since #If False is never true, these commands are stripped from your code before being sent to the compiler.
Of course, it is less convenient to disable code this way because you actually have to type in the commands. A contextual "Wrap this" menu might be useful here. I created a Feedback case for this: 20397
Errors and Warnings
The discussion brought up a couple other useful Pragmas: Warning and Error. To be perfectly honest, I never noticed that these pragmas even existed! It turns out they were added years ago (Real Studio 2008, according to the Language Reference).
Something that I do often is mark code that I need to go back to for some reason. Typically, I add a comment at the top and put TODO in it with a description:
// TODO: Fix this nasty hack
I think that usage stems from my Visual Studio days. I would then periodically search the project for TODO and would have a list of things I need to address.
It turns out you can get even better behavior using #Pragma Warning:
#Pragma Warning "Update this code to use Menu.Clone."
Dim selectedMenu As MenuItem
selectedMenu = EditMenu.PopUp
Your project runs just fine, but when you Analyze Project (or Item), this warning is displayed in the Warnings List. I really like this and will start making more use of it.
The related Error pragma generates a compile error:
#Pragma Error "Stopped the compile."
I haven't thought of a good use for this yet, but I'm sure someone can enlighten me!
Tuesday, February 21, 2012
Mountain Lion and GateKeeper
Last week, Apple surprisingly announced the next release of Mac OS X: Mountain Lion. They also officially dropped the "Mac" part, so it's actually: OS X Mountain Lion.
Not only did they announce Mountain Lion, they also made it available for members of the Mac Developer Program for testing.
Like everyone else, I was quite surprised to see a new version of OS X announced by Apple so soon after Lion, which was only just released in July 2011. In fact, I only just upgraded my main Mac to Lion about a month ago!
With this progress comes questions and for Real Studio developers, some of those questions are about the new GateKeeper feature.
GateKeeper
GateKeeper is a newish security feature that aims to prevent users from launching compromised applications.
In Mac OS X Lion, the first time you launch an application downloaded from the Internet, you are prompted with a warning:
This is called "File Quarantine" and was introduced in Mac OS X Leopard.
GateKeeper extends File Quarantine to do a few other things. Essentially, GateKeeper really wants you to only run applications that have been digitally signed to ensure their authenticity. Why? Because if a signed application is hacked (to add malware, for example) or otherwise modified, then the signature is invalidated and OS X will not run the app. A valid signature tells the user that this app has not been modified by anyone other than the original developer.
This is all controlled with a new System Preference containing three options:
- Run Mac App Store Apps only
- Run Mac App Store Apps and Apps that have been digitally signed
- Run any app
Option 3 is the same as things are now with Lion (and Snow Leopard and Leopard). Option 2 is going to be the default with Mountain Lion. Option 1 is for your parents.
A digitally signed application is an application that has been signed using a certificate provided by Apple to you. So what does it mean for Real Studio developers?
If you are already submitting apps to the Mac App Store, then you are a member of the Mac Developer Program and can sign your applications using the certificate you already have. The command-line tool (codesign, provided with Xcode) is used to sign your apps with your certificate using syntax like this:
codesign -f -s "3rd Party Mac Developer Application: Your Company Name" --entitlements entitlements.plist "AppName.app"
You can start signing apps not submitted to the Mac App Store at any time; they will work fine in Lion, Snow Leopard and Leopard.
For those that are not members of the Mac Developer Program, you do not yet have a certificate to use. According to John Gruber's post about Mountain Lion, Apple will not require you to pay to get a certificate. But they have not yet specified what this free method will be, so we have to wait and see. It is really in Apple's best interest to have the certificates be freely available, so I'm confident a free way to get them will appear soon.
GateKeeper Limitations
There has been much concern that GateKeeper will completely prevent some apps from running at all and that it gives Apple the ability to remotely "kill" applications. Both of those concerns are false.
First, GateKeeper only runs when the app is first launched. If the certificate is proven valid at that time, then the app will launch. The certificate is not checked again.
Apple can certainly invalidate certificates, but that will only prevent the app from being run on someone else's Mac, someone who has not already run it. Invalidating a certificate does not give Apple the ability to "kill" or remove previously installed applications.
Secondly, even with the most restrictive setting of "Mac App Store Applications only", you can still force an app to run by right-clicking on it and selecting Open. This will display a warning that lets you override the restriction and run the application. Again, you only have to this the first time you run the app.
Final Words
I hope this helps you understand GateKeeper a bit better. And rest assured, the team at Real Software is investigating Mountain Lion further. But due to NDA, we won't be able to comment on specifics until it is released.
Subscribe to:
Posts (Atom)