This week's book giveaway is in the Functional programming forum.
We're giving away four copies of A Functional Approach to Java: Augmenting Object-Oriented Java Code with Functional Principles and have Ben Weidig on-line!
See this thread for details.

Dave MacLean

author
+ Follow
since May 10, 2011
Dave likes ...
Android Java
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
3
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Dave MacLean

I know almost nothing about Kotlin, but have made many Android apps in Java for a long time. Are there aspects of Kotlin that are very different from Java for Android? Are there any types of Android apps (other than games) that should not be attempted in Kotlin? Thank you.
4 years ago
Maybe I'm too old-school, but I remember when browsers limited simultaneous connections to a server to 2. I would suspect that a browser running more than 2 web workers would still throttle on 2 connections (causing the third, fourth, etc to wait), so you'd have difficulty killing a server with lots of connections from lots of web workers. May make starting up lots of web workers kind of pointless if your goal is to download lots of content in simultaneous threads. I found this page that talks about the 2-connection limit:

http://www.openajax.org/runtime/wiki/The_Two_HTTP_Connection_Limit_Issue

- dave
The code takes an input parameter (csvData) as posted from the browser, and sends it back with an HTTP header (ContentType) such that the browser will receive it as a CSV file. If Arpit shared the URL for his JSP we could all call it from web pages to convert any CSV data to a CSV file via a browser. He didn't post the Javascript though that he used to call it/post to it.
Have you tested web workers with the major mobile browsers, such as the stock Android browser, or Mobile Safari? I'd be worried about those browsers running out of memory, or lacking the horsepower to perform background tasks. Thank you.

- dave
I like to say that a good architect knows the materials. While I might not expect a building architect to have experience pulling cables, I would expect a good building architect to know about steel, concrete, glass, etc. If you're going to architect networks, you probably need some hands-on experience with networks (even computer cables) somewhere in your past. You'll learn to appreciate subtle aspects of networks you won't get from listening to a lecture. The more varied your experiences are, the more valuable you become as an architect.
11 years ago
Regarding a print version of Pro Android 3 in India, here is the response from our publisher:

Management is working to find a distributor in India but this is still in the works, I believe the books will be significantly cheaper if they are printed and distributed in India. I don't have anything other than that to say on this matter but just know that it is in the works.

So there you have it.

- dave
12 years ago
In chapter 4 of Pro Android 3, Satya covers how to create a new SQLite DB using DDL within the Android application. The sample code for our chapter 4 can be found from http://www.androidbook.com/projects. But it should be possible to copy files from assets within your APK to the /data/data/<yourpackage>/databases directory to use them from there. Here are a couple of posts on stackoverflow.com that you might find useful:

http://stackoverflow.com/questions/4434367/copy-my-own-sqlite-db-from-asset-folder-to

http://stackoverflow.com/questions/4989300/having-problem-while-copying-sqlite-database-from-assets-to-data-folder

- dave
12 years ago
Congratulations to the winners! I'm glad we had this chance to connect with all of you. Thank you for your interest in Android, and happy coding!

- dave
12 years ago
Unfortunately, Proguard was not a feature we covered in the book. We wanted to but just couldn't fit it in. We mention it briefly but don't get into the details.

I know what you mean about the good and the bad. The tool does a decent job of obfuscating but sometimes can go too far, which is where it gets difficult to use. You have to go in and tweak the settings so it won't muck up stuff that you need left alone. But it can help you fight piracy of your app. Sometimes the reason for this is that users want to buy your app but they can't get it from their country's Google Android Market. So they look for some other way to get it. This is one reason why you should always consider alternate means of distributing your apps. You can sell through Android Market and also through other sites. We discuss the legalities of Android Market in chapter 28 and this is definitely okay. That way you could make it easier for users to find it so there's less reason for piracy.

- dave
12 years ago
Compiles in Eclipse should be really fast, especially for the Hello, World sample application. If you're talking about the time it takes to launch the Android emulator, yes that can take a long time. The higher the OS version and the larger the screen size of the device you're emulating, the longer it will take to start up. Mark's advice is excellent; you definitely want to fire up an emulator and leave it running while you work on your app. You can deploy over and over again to the same emulator as it runs, and you won't have to wait for the emulator to start up every time.

As an aside, the Android emulator is at the hardware level of the ARM processor. Which means it's doing a ton of work to run your apps. It also does not support any graphics hardware acceleration, so you can forget about emulating anything that involves video.

Here are some extra tips regarding emulator management. When you create your Android Virtual Devices (AVDs), make sure you check the Enabled option for Snapshot. You can also edit an existing AVD to enable a snapshot. This is like hibernating a laptop. When you shutdown your emulated AVD, the emulator can save out a snapshot of the running AVD to a file (a big file!) When you startup, you can start from a saved snapshot and it goes much quicker. Of course the first time you startup a new AVD, you cannot start from a snapshot because there won't be one yet. And the first time you save to a snapshot it can take a lot longer than if you don't. But now you have some interesting options. You could start up a brand new AVD, and when it's all up and running, immediately quit it which will save it to a snapshot (you choose this option when you start it up). Now you have a clean snapshot. Next time, check the box for starting from a snapshot but don't check to save to a snapshot at the end. This keeps your snapshot file nice and clean for fast starts, and it will shut down quickly too. We cover this in chapter 2. Of course you can always play with these checkboxes to get what you want into the snapshot file. You can also move and copy snapshot files around if you like. But keep in mind they can be very big.

- dave
12 years ago
If I'm correctly understanding what you're trying to do, the problem is with "localhost". You're trying to connect to the external database from within your Android environment. Android is running Linux underneath, so you've got an operating system there, and localhost to that OS means the Android device. What your code says to do is open port 3306 on the Android device. You'll need to give the IP address of your external host to connect to it from Android.

- dave
12 years ago
That should work in the emulator, but how are you turning the network off? Did you press the F8 key in the emulator?

Also, did you request the ACCESS_NETWORK_STATE permission in your AndroidManifest.xml file?

Lastly, you may want to use just isConnected() instead. The NetworkInfo may report true for isConnectedOrConnecting() when the network connections appear to be possible but even if you aren't able to use it yet. I also found a post that suggested using isAvailable() as well in your checks.

- dave
12 years ago
Sorry Andrzej, some confusion on our part. Our book is Pro Android 3 and it's being featured this week in this forum. So when Satya saw your post, he thought you were referring to a problem in chapter 7 of our book. But you're talking about Reto Meier's book. You could try reaching him directly through his blog: http://blog.radioactiveyak.com. Hopefully he will help you fix the problems.

- dave
12 years ago
Here is some more information on the topic.

First off, I want to clarify something that Augusto said about wanting all images in the apk file. The apk is static, fixed, read-only. It is ideal if your images don't change so you can include them with your apk (under /res/drawable, or /res/raw or /assets). But of course you can't update these images at runtime. You can only update the images by updating your application by releasing a new apk. So if you want to update images by downloading them, you can't have them in the apk.

There is another method I should have mentioned for downloading files from the network. The DownloadManager class can be used to download files in the background. There's a sample program in chapter 11 to demonstrate this. It would typically be used for large file downloads but you could try it for small files as well.

And one more class that you may want to consider, assuming your image files are small: the brand new LruCache (in Android 3.1 and in the compatibility package). LRU = least recently used. It basically forms a queue of objects and as you access items, it moves them to the front of the queue. When you add an object, if the queue is full, the new object goes on the front and the last object is dropped off the back. If you size this cache to the number of images you want to work with, it should work. It's so new I haven't had a chance to try it out yet myself, but it's worth a look.

- dave
12 years ago