Hello Dlmuthu,
*We are talking about my second solution here which is to allow users to
create model/entity classes and we provide a method to map the parsed web
responses into data members within the model. *
I did not want to force a one to one correspondence between what is on the
server and what is on the android client. This is because, the server side
applications usually might be a super set of what we need on the client
side. So by forcing a one to one correspondance we maybe adding
unnecessary fields in the models on Android ( or any other client side ).
As far as android is concerned, most mobile development projects begin with
a ER diagramming ( or more informal equivalents of the same ). The
developer will most definitely have clear understanding of what the
entities/models are and what are its associated data members. So, I don't
think it will be a difficult task in hand for most mobile developers.
I'm still thinking about my first approach , which is to generate the
client side sdk library on the server side via dependency injections. Give
me few days to think about this. I will get back with an appropriate
solution.
Thanks,
Deepak
On Mon, Apr 15, 2013 at 12:22 PM, DImuthu Upeksha <
dimuthu.upeks...@gmail.com> wrote:
> Hi Deepak
> Regarding your second approach I would like to add new idea. You may have
> been familiar with java frameworks like persistence or hibernate to access
> database. Why can't we apply that concept to your approach. We have set of
> entity classes in our android application (we say it model layer) same as
> the Models used in web service (If there is a model called Student in web
> service we also create a entity called Student). Then the problem is how
> can we exactly know the attributes of that entities . As a solution for
> that we can write some test cases to check whether our model classes are
> exactly compatible with models in the server. If a test fails then we know
> some entity is not compatible with the server model. We can simply access
> our entity classes to access domain classes in web service.
>
> NOTE- This is exactly similar to your approach only difference is we can
> use test cases to test compatibility instead doing it manually
>
> Advantages.
> 1 It can be defined as a standard representation so users can easily get
> used to it.
> 2 Because test cases are responsible for checking compatibility between
> server and client models we don't need to go and check server models'
> attributes manually. (Because I'm lazy to do such things :-) )
>
> Disadvantages
> 1 As you mentioned, there could be some dependencies with web service.
>
>
> On Sun, Apr 14, 2013 at 10:06 PM, Deepak Gopalakrishnan
> <dgk...@gmail.com>wrote:
>
>> Hello Dimuthu,
>>
>> Iven't finalized my solution yet.
>>
>> The first method requires the user to generate the library from the
>> server side instance. I will elaborate the advantages of this method later
>> in this thread. The major disadvantage is that the library has to be
>> generated each time the web services change.
>>
>> For the second method, I think the best approach would be to return an
>> instance of a BaseResponse class ( that extends HashMap ). This class can
>> have a method that will clone the hashmap elements into a model class (
>> defined by the user ) according to the names of the data members.
>>
>> Example :
>>
>> After the method returns the HashMap ( which is the BaseWebResponse class
>> ) will contain ("firstName"-> "Deepak", "lastName"-> "K", 'age'->25)
>>
>> Suppose the user has defined a new model class called User { private
>> String firstName, lastName; private int age; //and the accessor methods
>> included }
>>
>> So the keys of the hashmap can directly correspond to the datamembers. We
>> can have a Object baseWebResponse.toClassOfType(Class classType) method
>> within the BaseWebResponse class which will do the conversion.
>>
>> Thanks,
>> Deepak
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Apr 15, 2013 at 10:10 AM, DImuthu Upeksha <
>> dimuthu.upeks...@gmail.com> wrote:
>>
>>> Hi Deepak,
>>> I was thinking about your two approaches regarding DAO for android
>>> client. Using dependency injection to create those domain classes makes
>>> sense and I need to do more reading about dependency injection
>>> Regarding your second approach, having a generic DAO class and using
>>> methods like GenericDao.getEntity("Student").getData("getPassedStudents")
>>> leads to a problem I think. Basically what is the return type of this
>>> method? It should be a set of Student entities. But we don't have a Student
>>> class in our application. As a solution we can use a Hashmap like thing to
>>> return attribute name and value pairs. But I'm not sure about the
>>> applicability of it because attributes of Student class may have complex
>>> objects.
>>>
>>>
>>>
>>>
>>> --
>>> Regards
>>>
>>> W.Dimuthu Upeksha
>>> Undergraduate
>>> Department of Computer Science And Engineering
>>>
>>> University of Moratuwa, Sri Lanka
>>>
>>
>>
>>
>> --
>> Regards,
>> *Deepak Gopalakrishnan*
>> *Mobile*:+918891509774
>> *Skype* : deepakgk87
>> http://myexps.blogspot.com
>>
>>
>
>
> --
> Regards
>
> W.Dimuthu Upeksha
> Undergraduate
> Department of Computer Science And Engineering
>
> University of Moratuwa, Sri Lanka
>
--
Regards,
*Deepak Gopalakrishnan*
*Mobile*:+918891509774
*Skype* : deepakgk87
http://myexps.blogspot.com
