OrmLiteConfigUtil writeConfigFile doesn't work on android studio

[bolds07]

I was starting a new android project and decided to check for an ORM since wouldn't be reasonable to use hibernate on it (which i'm familiar to)

I found this api on a blog making a comparsion on ORM to android then i decided to try it.

I configured the whole project structure (which looked to me pretty unhappy, if you do have an high adopted and known standard as JPA why the hell create such weird annotations? if you didn't want to include a new dependency you could just create similar named annotations....)

then following the guide

4.2 Using Table Config File When the utility is run it should create the ormlite_config.txt configuration file in the raw resource folder. This folder must exist before the utility is run. Afterwards, if you refresh your project your should see the file appear. In the Eclipse console, you should see something like the following outputted by the utility:

I kept getting Could not find raw directory which is typically in the res directory even if knew there was a res/raw folder

Well I debuged the execution of this code and got the worst impression of what i saw... a very pathetic file finder running trying (unsuccessfully) find the raw folder... my impression of what i saw was so bad that at this moment i decided to throw away the whole configuration i had already done to use this api and starting from scratch...

yes because if an api has such disappointing approach to do one simple task, what to think about its capacity to handle complex tasks?

1. you could let the user pass the whole raw path as a parameter
2. you could simple create a config file at the root of the project and let the user to move it
3. you could simple print it to console and let user create a file under the raw folder

this is what comes on top of my mind... but instead you decided to create a rudimentar file finder based on directory name convention and failed...

This whole report is just an advice for the api maintainers... when writing any code don't try to be smarter than it need to be... a workaround that needs another workaround is pretty much useless

[j256]

Thanks for the feedback. Frankly I'm not an Android programmer so although I can stand by the generic java and the jdbc side of the code, the Android side does need some work. Feel free to submit some code which does a better job.