Remember the great Delphi for Android wallpaper? Well Dave has a new wallpaper to celebrate the new C++Builder for Android support.
Thanks Dave for the great new wallpaper!
Category: Android
Categories
Setting Android Settings
On the Android platform all the system wide settings that are accessible via the Settings app are also accessible to your app. You just need to add the uses permission WRITE_SETTINGS. Here is a simple Delphi XE5 example for changing the screen timeout.
First you need the following in your uses clause:
Androidapi.JNI.Provider, // JSettings_SystemClass FMX.Helpers.Android; // SharedActivityContext
Here is the code to read and set the Screen Off Timeout:
function GetScreenOffTimeout: Integer;
begin
Result := TJSettings_System.JavaClass.getInt(
SharedActivityContext.getContentResolver,
TJSettings_System.JavaClass.SCREEN_OFF_TIMEOUT,
15000); // 15 seconds is default is not found
end;
function SetScreenOffTimeout(ATimeOut: Integer): Boolean;
begin
Result := TJSettings_System.JavaClass.putInt(
SharedActivityContext.getContentResolver,
TJSettings_System.JavaClass.SCREEN_OFF_TIMEOUT,
ATimeOut);
end;
In the GetScreenOffTimeout we pass a default value to use if none is found. I passed in 15000, which is 15 seconds, or the smallest value for my phone. The largest value on my phone is 600000, which is 10 minutes. It appears you can set it to any value, even one that the settings app doesn’t explicitly list as an option.
There are lots of other settings available for your adjustment.
Few weeks ago I posted about how to launch a Google Glass app with a voice command. The app I built used buffered sensor data from the accelerometer and smooth animation to show a level. The video below is from our Making the Connection: Programming Devices and Gadgets with RAD Studio where I put all the pieces together.
Google Glass is an exciting new platform and form factor. Éric Bonilha from Digifort joined us to show interfacing IP Controllers and streaming video from IP Cameras.
Something we didn’t get to show is Éric built a prototype app for streaming video to Google Glass. His plan is to build a version of his camera surveillance app for Google Glass that will stream surveillance video to security guards on patrol. Additionally it will stream the video from Google Glass back to the security system.
It was so cool how fast Éric used Delphi XE5 to prototype accessing the camera on Google Glass and streaming video from his system to it.
The source code for my Google Glass app, and Éric’s code for accessing IP Camera & IO Controllers is available along with the replay from our RAD-In-Action Webinar. I’m looking to pick up a PTZ IP Camera and streaming it to my Google Glass next.
Turns out there are a few ways to scan a barcode with RAD Studio XE5, and no sooner do I make a video about it then TMS releases a component to scan barcodes, and then Thomas Krampe sends me his component that combines them all together.
Not that we need another barcode scanning app on our smartphones, but it can be a useful feature for an app that performs another purpose to be able to scan a barcode too.
This video was part of our Making the Connection: Programming Devices and Gadgets with RAD Studio webinar. Check out the on demand replay to get the source code.
My first thought when I see cool technology is to figure out how to connect to it with Delphi. So the day I got the Parrot AR.Drone 2.0 quadricopter I started working on Delphi interface. By the time evening rolled around the batteries were dead (after a couple recharges), but I had a basic interface working. The official developer guide seemed to be a little out of date, or I was reading it wrong, but once I got my facts staight, connecting was really easy. http://www.youtube.com/watch?v=aaGe2aERwgI The Parrot AR.Drone has it’s own access point. Once you’ve connected to it, then it is simply a matter of sending UDP packets for the basic controls. To accomplish that I simply used the Indy UDP Client: TIdUDPClient. Each command is sent with an increasing sequence number, so I initialize my interface as follows:
udp := TIdUDPClient.Create(nil); udp.Host := '192.168.1.1'; udp.Port := 5556; seq := 1;
The AR.Drone is always at 192.168.1.1 since it is the access point, and the port for communication is 5556 (one of a few ports, but the one we need for now.) It is worth pointing out that if you’ve previously flown your AR.Drone with the FreeFlight mobile app then you may need to reset your drone to unpair it. Otherwise it is paired to only that device. The commands are formatted with an AT* prefix, and a series of arguments. For example, to take off, the command is AT*REF=1,290718208 where AT*REF is the command, 1 is the sequence number (always the first argument) and 290718208 is a bitmask that means take off. I created a SendCommand routine that looks like:
procedure TARDrone.SendCommand(cmd, arg: string);
var
full: string;
begin
if not udp.Active then Connect;
full := Format('%s=%d,%s' + Chr(13), [Cmd, Seq, arg]);
Seq := Seq + 1;
udp.Send(full);
end;
Notice the command is terminated with a carriage return (#13). The documentation says line-feed (#10), it is wrong. Supposedly you can send multiple commands in the same message, if they are separated by the carriage return. I haven’t tested that. Then I can send the some common commands like this:
SendCommand('AT*REF','290718208'); // Takeoff
SendCommand('AT*REF','290717696'); // Land
SendCommand('AT*CONFIG', '"control:altitude_max","10000"'); // unlimited altitude
SendCommand('AT*CONFIG', '"control:altitude_max","5000"'); // restrituded altitude - unsure what units 500-5000.
SendCommand('AT*PCMD','1,0,0,0,0'); // Hover (stop movement)
PCMD is the move command. It takes 5 arguments (after the sequence number.) The first is the controller type, which we are leaving 1 for now. The next 4 are phi, theta, gaz, yaw and they are floating point numbers in an integer representation. This is where it gets interesting. The documentation says:
The number –0.8 is stored in memory as a 32-bit word whose value is BF4CCCCD(base 16), according to the IEEE-754 format. This 32-bit word can be considered as holding the 32-bit integer value –1085485875(base 10).
The first way I thought of to access the same memory as two different types is a variant record. So I came up with the following helper routine:
function IEEEFloat(const aFloat: Single): Integer;
type
TIEEEFloat = record
case Boolean of
True: (Float: Single);
False: (Int: Integer);
end;
var
Convert: TIEEEFloat;
begin
Convert.Float := aFloat;
Result := Convert.Int;
end;
Using that I built a move routine that takes 4 singles (32-bit floats) and sends them as integers:
procedure TARDrone.Move(const phi, theta, gaz, yaw: Single);
begin
SendCommand('AT*PCMD',Format('1,%d,%d,%d,%d',
[IEEEFloat(phi), IEEEFloat(theta), IEEEFloat(gaz), IEEEFloat(yaw)]));
end;
Now if I want the drone to go up I can call:
Move(0,0,5.6,0); // positive gaz is upward acceleration
Now it is just a matter of figuring out how to the rest of the movements map to the physical worked and building a user interface on Android, iOS, Windows or Mac. Maybe all 4! Once I build up the API a little bit more I’ll share some full working apps and libraries. Let me know if you are interested in collaborating on such.
Categories
Every Android API for Delphi
Delphi XE5’s support for Android includes many of the most common Android APIs either wrapped in nice cross platform libraries and component or accessible directly via the JNI wrappers. The rest can be accessed by creating headers to expose them. The new JNI Bridge makes this calling of the managed Java APIs from the native Delphi app much easier then it used to be, but it still takes a little effort to make the translation (it is easier than translating a Windows API). Brian Long (an Embarcadero MVP) has an excellent video from CodeRage 8 that goes into great detail on the process.
But all of that has now changed. CHUA Chee Wee aka “Chewy” (also an Embarcadero MVP) has released an Android2DelphiImport tool that makes wrapping and accessing any and every Android API much easier. It gives you 3 distinct benefits:
- You can point it at Android.jar in the Android SDK and have it create wrappers for EVERY Android API. You’ll need to copy and paste out the pieces you want (it puts them all in one source file), but it saves a lot of typing and research. It implements the wrapper using the JNI Bridge just like the RTL does.
- You can point it at any other built in Java library, like the Google Glass GDK that provides all the Glass specific features on Google Glass, or maybe the Google Cloud Messaging (GCM) API. You’ll have a source file that wraps all the API calls exposed in that JAR file.
- You can use it to wrap a 3rd party Java JAR file for Android and it will create a .PAS interface for it, bundle it up for inclusion in your Delphi app, and load it at runtime.
As a matter of testing this tool I pointed it the Android.jar file for Kit Kat. It took a little while, but when it was done I had over 100,000 lines of interface wrappers covering EVERY Android API on Kit Kit. I copied out the lines for Toast support, added in the necessary uses statements, and I had full toast support in just a few minutes.
My next test was to point it to the Google Glass GDK (Glass Development Kit) for building native Glass Apps. Previously I had only used the Android SDK & NDK, which supports the common Android functionality on Glass, but the GDK adds support for Glass specific features. Once the GDK is installed (via the Android SDK Manager under API 15) you will find gdk.jar in the sdk\add-ons\addon-google_gdk-google-15\libs folder. It created a nice wrapper for it, but that wrapper wouldn’t compile because the uses clause was incomplete (it has a notice that you need to adjust the uses clause). I had to track down 4 additional units for the uses clause and then I extracted 3 more apis from the earlier Android wrapper to cover APIs that weren’t previously exposed. In all it took me about 15 minutes and then I had full support for the Google Glass GDK.
Since compiling isn’t enough, I built a simple app to insert and remove cards on the Google Glass timeline. It worked like a charm. I didn’t need to tweak or adjust the generated code at all (beyond the uses clause). Here is my code:
tm := TJTimelineManager.JavaClass.from(SharedActivityContext);
card := TJCard.JavaClass.Init(SharedActivityContext);
card.setText(StringToJString('Hello Glass'));
card.setFootnote(StringToJString('From Delphi'));
id := tm.insert(card); // Use id to edit or remove card later
I haven’t tested the 3rd scenario yet, but I did observe how it works. The tool creates a .apk out of the selected JAR file. It then includes a routine to load that APK at runtime so you can call into the methods it includes. You would need to go this route when the JAR isn’t built into the platform already. I have a library that I’m planning to test this with (so stay tuned), but I wanted to blog about the other benefits right way.
I am really excited about the potential of this tool. Not only does this mean you have even easier access to the entire Android API, but you also have easy access to all the extended APIs and 3rd party APIs. It has a simple command-line interface, and very few options, but when it works that is all you need.
Right now purchasing it is a little more complicated than using it. He only accepts Bitcoins, 1/4 Bitcoin to be exact. Based on the current exchange rate it is about $200 US, which is an excellent value for what you get (and considering how much effort has gone into its development). So you will either need to mine or purchase a bitcoin to pick this tool up, but if you are doing Android development I highly recommend it.
Categories
Learning from Digifort
You’ve probably seen Éric Fleming Bonilha videos showing off his Digifort mobile applications developed with Delphi XE5. The videos don’t mention it, but the back end server and client applications are all written in Delphi too. Just in case you haven’t see the videos, here they are again:
Earlier version, but on a lot of different devices:
Embarcadero just completed a case study with him too, which is really informative. I spoke with him down in Brazil and he said they previously developed mobile clients with both Java and Objective-C, and found Delphi let them develop their projects much faster, and they get both Android and iOS from one project. Also, and perhaps more importantly he said the performance of the Delphi client was just as good, plus they found it more flexible for building a user interface that looks great and is easy to use.
Digifort may be based in Brazil, but their clients are all over the world and are a mix of government agencies and business of various sizes. Eric arranged a trip to meet me in Scotts Valley this last week. He showed me some pictures of some of the walls of monitors his clients have, all powered by Digifort. Some really impressive installations.
A big part of his trip was to pick up a his very own Google Glass to start developing a Digifort mobile app for Google Glass. In just a couple short sessions he was capturing images from the built in camera, connecting to his remote server, and streaming live video from Brazil to the glass display. The use case for security personal to view cameras while on patrol, while sharing what they see with everyone else is a great one.
Eric also had a chance to visit with some people from R&D and product management and share his experiences working with Delphi XE5 and FireMonkey. Here are some best practices he found for making a really smooth user interface.
- FireMonkey handles PNG images really well. He makes a lot of use of transparent and semitransparent PNG images in TImage components. Layering, animating and zooming those images is what he uses to create some of those really great effects, like the joystick control for camera control.
- The TFloatAnimation and other animation effects are really powerful. He uses those extensively for smooth animations.
- He created the drawer interface using TFrames (he uses a lot of frames). The main (center screen) has a Pan Interactive Gesture on it. He looks at the gesture to see if it is horizontal (comparing the gesture start to a later gestsure event) and has traveled at least 10 pixels in that direction. Once that happens then he moves the edge of it with the current finger position from the gesture. He also tracks the speed of the movement, so if you let go then he uses another TFloatAnimation to smoothly finish the movement at the same speed.
- When the drawer starts to open he pauses all the video and other animations. This really increases the performance of the drawer animation.
- Anything that is not currently shown on the screen has its visibility set to false. So if the drawer is closed, then everything in the drawer is invisible (since it is in a frame he just sets the frame to invisible). This keeps it from rendering and gives what is visible all the processing power. This is a common suggested optimization with many mobile development tools.
- It is important to think about a mobile app’s interface as a mobile app. Don’t try to squeeze a desktop app onto a mobile device. That will only frustrate you and your users.
- In his lists of cameras he uses a TVertScrollBox and fills it with a custom component that contains TImages and TLabels. That gives him maximum flexibility for the drag to reorder (again a Pan Interactive Gesture). He did find that the TLabel has better performance than drawing the text manually inside his custom control.
There were a lot of things he shared where he spent a little extra time to get things just right, and that is what makes the difference for a really smooth user interface. When asked about the learning curve to move from Desktop VCL to FireMonkey Mobile he said there was just a little learning curve, but now he really likes FireMonkey better than VCL. There was talk about having him collaborate for a user interface webinar, which I’m sure will be very informative.
You can catch Eric’s appearance in our Devices and Gadgets webinar on the webinar replay (posting any day now). And download his sample code (along with the rest of the code from the webinar).
What are some tips and best practices you’ve found in your FireMonkey mobile development?
Working with sensors on devices can often lead to large amounts of data coming to you really fast. For example the TMotionSensor’s OnDataChange event fires 100 times a second on my Nexus 5. When I was building my level app for Google Glass the level bar was bouncing all over the place because of the sensitivity and sample rate.
My first thought was to only take every 10th sample, but I wasn’t happy with that either because the specific sample it pulled could be the one when there was a jitter.
Example: 1,2,1,1,2,1,2,3,1,3,12,2,3,1
If I just looked at sample 1 and 11 then I would see a lot of movement, but in reality it was relatively stable most of the time.
What I ended up doing was buffering the data and taking an average. I just created a generic TList of the appropriate type, and during the OnDataChange event I would simply store the sample data. When it came time to update the display I took an average sample, which I found gave a much smoother and more representational display.
Although it was still possible the line could jump erratically if I really moved a lot. So I decided to use an animation for the movement. This keeps the line movement smooth, even if there is a lot of movement (it interpolates the positions between the current line position and the new position). I used a TFloatAnimation and set the StartFromCurrent property to true.
When the animation is finished I set the StopValue to the the average of the values, then enable again. It is important to always clear the sample values after taking an average. Otherwise the movement will continue to get slower and slower as it becomes more and more stable (averaging a large enough sample of numbers results in a smaller range of results.)
I was really pleased with how smooth things looked with a 0.1 second duration on the animation. With 100 samples a second, this translates into each animation covering the average of 10 samples. The built in animations made it really easy, and the final display looked great.
I’ll include the source code with the downloads from the Making the Connection: Programming Devices and Gadgets with RAD Studio webinar coming up next week!
Skeuomorph is compounded from the Greek: skéuos (container or tool), and morph (shape). It describes something that possess additional ornamentation indicative of its inspiration. It is used to describe both physical objects as well as digital designs.
In the physical world we frequently see it as something made of plastic that is styled to look like leather, wood, etc. In the digital world it shows up when a button or other digital element contains textures, shading, etc. to make it look like the physical element that inspired it. From a design point of view in digital assets it is useful in that the user recognizes what an object represents by its physical familiarity (called an affordance).
Apple’s platforms used to be full of a great examples of Skeuomorphism. On iOS all the default icons had a glare that made them look 3D. Many apps, had a extra details to make them look lifelike. Take the Notes app, it was full of torn bits of paper, leather borders, stitching, paper lines, etc. The new version doesn’t have any of that (although it does have a slight paper texture).
iOS 7 didn’t lead the move to non-skeuomorphic design. Windows Phone 7 (the predecessor to WP8 and Windows 8) and the Metro design eschewed skeuomorphism completely. (If you are keeping score, iOS 7’s features were inspired by Android and design inspired by Microsoft.) Android has always been been straddling the proverbial skeuomorphic fence. Although with the the other two mobile plays moving away from skeuomorphism I expect Android to follow.
iOS7’s move away from skeuomorphism really highlights how most apps design no longer tries to mimic the platform’s design completely. Users are creative with their apps, and often times bring their own design with their app across all platforms. That is the great thing about building your cross platform apps with Delphi. You can use the standard platform styles so your app looks like a standard app on each platform, or just as easily switch to a premium or custom style and have your app stand-out and look consistent across platforms.
Now you need to ask yourself if I only wrote this post so I could use words like eschew, skeuomorphic, proverbial and affordance.
Building a running an app on Google Glass is easy with Delphi XE5, but what about integrating it into the Glass menu system and launching it with a voice command? Turns out that is pretty easy too.
First of all, I find it easiest to to add AndroidManifest.template.xml to your project. It shows up in your project folder after you build an Android app the first time. This template is for the AndroidManifest XML file that is used to describe your application to the Android OS. We open this file and find the
<action android:name="com.google.android.glass.action.VOICE_TRIGGER">
This tells it that our main activity is eligible to receive the VOICE_TRIGGER intent. Next we need to specify which voice command we want to receive. This is done by adding a <meta-data> element outside of the <intent-filter> element (but still inside the <activity> element).
<meta-data android:name="com.google.android.glass.VoiceTrigger" android:resource="@xml/voice_trigger_start">
This specifies that there is VoiceTrigger metadata in the xml file voice_trigger_start.
Update: Thanks to the Glass XE16 KitKat update, a special permission is required to use a non standard voice trigger command. In the Manifest, right below the <%uses-permission%> line you need to add the following special
permission:
<uses-permission android:name="com.google.android.glass.permission.DEVELOPMENT">
So now we need to create that XML file. Simply right click on your project in the Project Manager and select Add New, then under Web Documents select XML File. Rename it to voice_trigger_start.xml, save it, and edit it to look like the following:
<!--?xml version="1.0" encoding="UTF-8"?--> <trigger keyword="My voice is my passport, verify me.">
The value of keyword can be any word or phrase that you want to associate with your app. This will be used in the sentence of “OK Glass, my voice is my passport, verify me.” Generally you want to keep it short, like “take a picture” or “get directions”, while not using something that conflicts with a built in command. This is also what will show up in the launcher on glass next to your app icon.
Now we use the Deployment Manager to specify the location for this new XML file. Simply go to Project \ Deployment and select Add File and choose the voice_trigger_start.xml file. Then change the Remote Path to res\xml.
Simply run your app from the IDE (after you’ve installed a Google Glass USB ADB driver) and after that you can launch your app from the Glass launcher or your selected voice command.
What to learn more about other devices and gadgets? Join me for my free webinar on Programming Devices and Gadgets with RAD Studio on January 22nd.