James Gibbs

Greenhorn
+ Follow
since Feb 21, 2013
James likes ...
Android Ubuntu
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
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 James Gibbs

Thanks Ulf and Matt, with your help I saw the errors of my ways and got it working.

Matt, thank you so much for your advice about the inner if conditional, when I was writing it I was thinking "there has to be better way", did consider && but had completely forgotten that it short circuits so thought if I used it it might blow up if x.equals("yes") was run before the null check.
10 years ago
ah thanks I see what you mean. Now it changes my question how I convert a JsonNode to a Row? maybe I'd be better off with a for loop
10 years ago
I'm trying to iterate through a list and add all matching nodes to another list. However in the specific line affiliateResults.add(iterator.next()), iterator.next doesn't return an object, as when I later inspect affiliateResults it is empty. Any ideas where I'm going wrong?

10 years ago
I'm building an Android app which replicates a CouchDB using TouchDB. I create a view with all the documents and pass it to my own implementation of CouchBaseViewAdapter, which links it to my ListView:



In the SyncListAdapter I override getView() and try and extract the "header" field of each JsonNode which has each has been mapped to the results of my viewquery by Ektorp:



However item.get("header") always returns null, even though the same amount of list items are populated as the amount of docs in the DB, so I assume everything else is working.
Sounds like its quite a nice tool to have. I was able to plug the amazon xml into my existing xml parsing code with minimal code change and have it work, so didn't bother with simple xml. But if I ever have to touch xml on android again unless its very basic it'll be simple xml all the way.
Sorry I meant storing my JSON objects in a DB instead of to file.

Since my first post I've found an lightweight mobile specific implementation of CouchDB for Android called TouchDB which enables replication of a remote CouchDB. I'm guessing this should do away with mappings between JSON objects and my own POJOs?

TouchDB isn't ver 1.0 yet so could potentially blow up in the my face, but it sounds like a nice rapid solution with the possibility of scaling it up if I need to?
11 years ago
I'm trying to build my first web app and currently struggling to find the right path to take.

I'm building a simple Android app which will read POJO's from my web app. There won't be any write access by the android app.

I'll need to build a web app which will have a admin front end for me to do simple CRUD operations on the objects, using a REST setup.

So far i've figured out I can use the Play framework (so I can stick with Java) and JSON (for reduced mobile bandwidth) as a transport method.

Now this is where im getting a little stuck. Firstly I decided I wanted to keep it simple and just serialise the JSON objects to text files. However realize this probably wont scale well, so will probably need to go down the DB route.

Because I'm using JSON would MongoDB be a good choice? Do I need to use a ORM to map between JSON/POJOs/MongoDB?

Update: I've edited this question, was considering using reactivemongo module for play to do away with POJO's/ORM but realised it uses Scala, haven't got the bandwidth to learn Scala aswell!
11 years ago

James Boswell wrote:
Using a Set would remove duplication of categories i.e. duplicate categories specified in the text file.

By the way, does your web service use an XSD for its interface? You could use the schema to define the categories and also handle duplicates.



Ok that makes sense, I'll use a Set.

I was planning on using JSON, XSD is for XML right?
11 years ago
Thanks Jeff that really cleared it up for me. I'll be avoiding implementing that like the plague then.

Back to my original question, am I just over thinking this? Decided that I'll be reading the categories from a simple text file:

Cat1
Cat2
and so on.

Should I just bung them in a ArrayList and be done with it? Looked at Set and it doesn't seem to bring anything to the table.
11 years ago

Campbell Ritchie wrote:It is also probably better to create constants in a class than an interface; there is then no temptation to implement it and have those constants part of the public interface of the class too. An enum is a special kind of class, so that follows the same principle.



I'm definitely missing something here, if you never implement an interface how can it be used in Paul's previous examples? Are those examples a massive hack which were used pre enums? Are you secretly turning the interface into a class with no methods? These are called marker/tag interfaces right? But I'm guessing Pauls examples arn't one of those?
11 years ago

Paul Mrozik wrote:Thanks a lot Steve.

I'm using an outdated Java (TIJ 3rd Ed.) book where I found this:

Because any fields you put into an interface are automatically static and final, the interface is a convenient tool for creating groups of constant values, much as you would with an enum in C or C++






I did think it seemed a little bit of unnatural way of doing things, was this then a work around to fake enum's before Java had that functionality? oh and thanks for the link im about to read it

Steve, I'm building a Play framework web service which is going to be returning the Product objects in JSON form to a Android app. The categories will possibly get renamed and new ones added. Would a Set<Category> be preferable then?
11 years ago
Thanks Paul, although I'm not sure exactly how your examples related to my problem, isn't that example more for creating a class with static methods?

11 years ago
Am building a new class which will represent product objects. Each object can belong to 1 or more categories. The category hierarchy will be flat.

Would the best way of representing what categories a product is a member of be with a simple ArrayList of strings? An enumerated type? Should I define the possible categories as a list of constants in the product class so I can check the correct categories are assigned on object creation?
11 years ago
Yeah I've taken a look at Jersey aswell, seems there's a lot of overlap between play and jersey. Think I'll have to try them both at some stage to get a good feel for them. So then it looks like it'll be JSON and Play! but im still undecided on how to store the data on Android and the Play server.

The web service will need to basically occasionally allow me to add/modify/delete items/objects. 99% of the time it'll either be idle or supplying the Android app with new objects.

On the Android side the app will most of the time be displaying selections of the items/objects and downloading new objects when required. There's only a few extra fields the app will create, such as if the item has already been viewed, favorited etc

I'm guessing my choices are either object serialization to text file(s) or a DB of some kind, maybe NoSQL on the web service and SQLite on Android....really don't know what to go for

Update: After hours of research I've come to the conclusion that serializing the JSON to disk on Android is going to be best bet. However I still don't know what to use for web service side?
11 years ago

SOAP has become unfashionable due to its overhead. Consider using a RESTful WS that transports JSON (Android has a JSOn API built in).

Storing it in memory is tricky, as Android may decide to kill your app at any given moment. Either use the built in SQLite DB, or store the raw JSON in internal or external storage: http://developer.android.com/guide/topics/data/data-storage.html. The latter is what I would do.



Thanks that's a great response. Would building this RESTful service in the Play! framework be a good way to go?

I'm guessing you think JSON would be better over SQLite in my case for reduced complexity?

Steve, thanks for the heads up on MQTT, I've taken a look at it, I still might go the google route for now as I'm still a beginner and I'm guessing they'll be more support/docs for their implementation. But MQTT might be useful to me in future
11 years ago