1

I'm trying to create a caching system for data downloaded from parse in my cn1 app, so that the app doesn't have to make a network call every time. I don't want to use the built in externalization implementation built into the parse4cn1 lib, because as I understand it writes each object to a file, and I want to cache whole queries with large lists of objects.

I ran into a problem trying to restore ParseUser objects (such as members of the current user's team) that were previously queried. I don't see any way to instantiate the ParseUser object without extending the class. Is that what I should be doing, or is there some other way to get around this problem?

My hesitation is that beyond this need I have no reason to subclass ParseUser, and if I register my subclass I assume it will have to use a different class name, and it will require a significant readjustment of other parts of my code.

Update

I subclassed ParseUser in order to expose an empty constructor, and thanks to polymorphism I didn't have to change any other code. It looks like this:

    public static class MyParseUser extends ParseUser{
        public static ParseUser fromData(JSONObject data){
            ParseUser user = new VqParseUser();
            user.setData(data);
            return user;
        }

        private MyParseUser(){
            super();
        }
    }

And then, in my code:

ParseUser parseUser = MyParseUser.fromData(json);

I'm still curious if this was the best approach.

ygesher
  • 1,133
  • 12
  • 26
  • Added the `parse4cn1` tag so this will be visible to people subscribed to that tag. I'm not familiar enough with the user mechanics of parse to answer this but I don't understand the aversion of multiple smaller files? – Shai Almog Oct 07 '17 at 05:12
  • I guess using multiple files would be just be much more cumbersome in the code than working with a single file, and I like the one-to-one query-to-file relationship that I'm currently working with. The caching architecture is not finalized, however, and I may end up changing it back to work with `Externalizable` – ygesher Oct 07 '17 at 18:07
  • Generally one file would mean reading it all since we don't support random file access (and if we did you'd still need to write the proper seek logic). Multiple small files are just faster. – Shai Almog Oct 08 '17 at 04:12
  • @jegesh It's been a while since I worked on the persistence interface but as far as I can quickly see, you're to a large extent in control of the granularity of your files. `Storage.writeObject(filename, obj)` creates a new storage file with that name (Shai will correct me if I'm wrong). So instead of storing one parse object per file, you can choose to bundle all your related query results in one collection and store that at once. Then you don't need to subclass `ParseUser` – netsuite_insights Oct 08 '17 at 07:08
  • ps: The Parse Java SDK implements a more elaborate data caching mechanism ([Local store](http://docs.parseplatform.org/android/guide/#local-datastore)) which should be replicable in `parse4cn1`. I just never got around studying it and porting the implementation to CN1's Externalizable interface but it should be doable without too much effort. Would that have been an attractive alternative in your use case? – netsuite_insights Oct 08 '17 at 07:13
  • It might be a good alternative, for my specific use case, but while I'm at it I decided to make something more generalized. – ygesher Oct 12 '17 at 21:40

0 Answers0