playMaker

Author Topic: Help with adding Playmaker support to Optimized ScrollView Adapter  (Read 52 times)

george0petrescu

  • Playmaker Newbie
  • *
  • Posts: 1
    • View Profile
Hey,

We've received enough request for this that we decide now it's the time to implement it.
OSA is a powerful ScrollView adapter that can display any kind of data as a list or grid.

This message is both for developers and Playmaker users, so sorry if some info is too technical - please ignore it, I'd really use your help with the other questions

We want to allow Playmaker users to use this asset with minimal code-writing and we need some help, because a lot of the ScrollView's behavior is specified by the user through custom scripts and overriding functionality.

For reference, a model is a data structure that describes what an item has (title, age, image, etc.)

Our major obstacles are:

1. How do I know where and in which format the user stores his data? 
ATM, they use a generic class named DataHelper<T> which does basic operations on an internal list, T being the plain C# class (that he needs to create) containing the specific fields (title, image, age etc.). Because he can retrieve these models from internet, local disc or simply create them manually, there's no single way of handling model creation/retrieval, so that's why that was left on the user. If you check the feature video for OSA, you'll see how different the data models can be from case to case (a chat is inherently different from a contact agenda, for example). Ultimately, maybe the solution is to still delegate the model creation/retrieval to the users, but doing it visually. Problem is it's not obvious what's the most common use case to start supporting the first time.

2. The Array (using Playmaker 1.9.0) can only store custom c# classes as UnityEngine.Object, and I tried making ItemModel (using this as an example) extend UnityEngine.Object, and simply creating them using "new ItemModel and it seems to be a probable direction we could take, but I'm not sure how we could handle massive data sets (OSA supports around 2 billion items, although obviously not all items are created at once - that's the whole point).

3. What's the most common way people are storing items in a list using Playmaker? Should I focus more on transforming json data directly into views (i.e. storing models as simple strings and converting them to a json object each time they're needed to be bound to views, and also automatically inferring which view takes which data), should I create a visual tool where they can design their item model and how each of its properties bind to what view?

All of these questions come from not knowing what an average Playmaker user would expect from a plugin like this. We don't want to work on something that won't ever be used.

We're really determined to provide support for Playmaker, so please let me know anything that you think would help bridge the gap between the 2.

Thank you so much for your time!

Best Regards,
George @ TFG

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 13512
  • Official Playmaker Support
    • View Profile
Re: Help with adding Playmaker support to Optimized ScrollView Adapter
« Reply #1 on: November 08, 2018, 11:13:50 PM »
Hi,

 Very good!

1: PlayMaker doesn't support out of the box random T class, you will need to wrap them into a proxy of some sort that then get exposed in the various playmaker actions. The best solution I found so far is to use soft referencing, using a dictionnary, you keep the key as the pointer to your complex data. I can go more into details if you want. But it means that somewhere you will have to maintain this look up table. That's what I am doing in DataMaker to allow PlayMaker to work with Xml and xpath. PlayMaker can not work with an xmlMode directly, but via a look up table, I can reference a xmlNode and do all the CRUD I need on it.

2: the built in Array variable is not suitable, as it can't reference simple class, it has to be a Unity.Object making it tricky for your case.

I would suggest a different approach. Could it be possible to use a GameObject prefab as the source for your cell? and create a proxy specifically designed for PlayMaker, then you develop the prefab with its proxy at the root?

3: I created ArrayMaker, a dedicated solution for working with arraylist and hashtables, and it works with a dedicated component and I expose access to it via a set of actions.

Both ArrayMaker and DataMaker are available on the our Ecosystem. But if you have no experience with PlayMaker, Maybe I should dive into your solution and get more acquainted with your approach and then propose a suitable solution to kick start the dev.


 Bye,

 Jean