Skip to content
This repository has been archived by the owner on Nov 29, 2017. It is now read-only.

Find a better way to determine if view is a tablet #126

Open
mcongrove opened this issue Feb 6, 2013 · 7 comments
Open

Find a better way to determine if view is a tablet #126

mcongrove opened this issue Feb 6, 2013 · 7 comments

Comments

@mcongrove
Copy link
Owner

Reference line ~392 in core.js (look for the TODO).

@rogerwhite
Copy link
Contributor

Reference line ~488 in core.js ?

@mcongrove
Copy link
Owner Author

Yup, that's the area. It'd be better to be able to detect if it supports tablet views instead of hard coding it, but that area of code is before it is instantiated.

@mcongrove mcongrove reopened this Oct 11, 2013
@rogerwhite
Copy link
Contributor

Came up with a simple quick solution. I don't know if this what you had in mind but I tested it and it works just fine on iOS. Did not try on Android but logically should work.

With the following solution, when creating a new component, you eliminate the need to hard code the Tablet views in core.js. Learned this hard way when trying to create a new component using the podcast component. Had named the component "streaming" and took a while to figure out that I needed to add the component name to the core.js for it to work in Tablet view.

It requires changes to 2 files.


  1. app.json

ADD "hasDetail" : true to all components that have detail views. Example below.

             {
        "title": "Flickr",
        "username": "39494278@N04",
        "apiKey": "e067644d8af6a8a9f2f36f8abbe32720",
        "type": "flickr",
        "image": "photo1",
        "cache": 1440,
        "hasDetail": true 
    },

  1. core.js

ADD NEW LINE AFTER line ~486 var type = APP.Nodes[_id].type.toLowerCase(); ( did not check to see if is still needed )

NEW LINE

var tabdetail = APP.Nodes[_id].hasDetail;

THEN REPLACE line ~490

                switch(type) {
                    case "article":
                    case "event":
                    case "facebook":
                    case "flickr":
                    case "podcast":
                    case "share":
                    case "vimeo":
                    case "youtube":
                        type = "tablet";
                        APP.hasDetail = true;
                        break;
                }

WITH

                if(tabdetail) {
                    type = "tablet";
                    APP.hasDetail = true;
                }

@mcongrove
Copy link
Owner Author

The problem with this method is that it requires non-technical users to remember to add that, or else it won't work.

That was our initial approach but we abandoned it.

Best regards,
Matthew Congrove

(Sent from my iPhone)

On Oct 12, 2013, at 3:27 AM, Roger White [email protected] wrote:

Came up with a simple quick solution. I don't know if this what you had in mind but I tested it and it works just fine on iOS. Did not try on Android but logically should work.

With the following solution, when creating a new component, you eliminate the need to hard code the Tablet views in core.js. Learned this hard way when trying to create a new component using the podcast component. Had named the component "streaming" and took a while to figure out that I needed to add the component name to the core.js for it to work in Tablet view.

It requires changes to 2 files.

app.json
ADD "hasDetail" : true to all components that have detail views. Example below.

         {
    "title": "Flickr",
    "username": "39494278@N04",
    "apiKey": "e067644d8af6a8a9f2f36f8abbe32720",
    "type": "flickr",
    "image": "photo1",
    "cache": 1440,
    "hasDetail": true 
},

core.js
ADD NEW LINE AFTER line ~486 var type = APP.Nodes[_id].type.toLowerCase(); ( did not check to see if is still needed )

NEW LINE

var tabdetail = APP.Nodes[_id].hasDetail;

THEN REPLACE line ~490

            switch(type) {
                case "article":
                case "event":
                case "facebook":
                case "flickr":
                case "podcast":
                case "share":
                case "vimeo":
                case "youtube":
                    type = "tablet";
                    APP.hasDetail = true;
                    break;
            }

WITH

            if(tabdetail) {
                type = "tablet";
                APP.hasDetail = true;
            }


Reply to this email directly or view it on GitHub.

@ndastur
Copy link

ndastur commented Oct 12, 2013

I would +1 this. Compared to general .json file editing I don't think this is too complicated. In order to edit such a file an element of technical knowledge is required. And for the majority of components the default value of hasDetail had be set and left.

@rogerwhite
Copy link
Contributor

Just a thought... Shoot me down if this is an option that will not fly at all. :) ..

How about keeping the same process intact until a better solution is found but letting custom component have the option of hasDetail : true in the json data file by doing something like:

    // Create a new screen
            var type = APP.Nodes[_id].type.toLowerCase();
            var tabdetail = APP.Nodes[_id].hasDetail;  //detect if data file mentions tablet view

            // TODO: Remove this. Find other way to determine if tablet version is available
            if(APP.Device.isTablet) {

                if(tabdetail) { //detection from data file
                    type = "tablet";
                    APP.hasDetail = true;
                } else { // built-in components hardcoded.
                    switch(type) {
                        case "article":
                        ...........................
                    }
                }

This would allow for the default components to have the tablet view hardcoded but in the meantime, custom components could be supported by adding the extra data in the json file. The benefit of this would be the upgrade process. No need to touch the core.js . Non-technical users would not be creating their own custom components so that would eliminate them from having to add the hasDetail value in the data file as they would presumably only be using the built-in components.

Using my scenario, I would have added the hasDetail: true to the "streaming" component tab in the data file and would not have to touch the core.js at all.

btw: I tried a couple of other options with no good results but kept coming back to this as this seems to be the most efficient solution without having to change a whole bunch of things that are already working great.

Are you open to revisiting your Initial approach to this or is this type of solution a dead end?

@mcongrove
Copy link
Owner Author

I'd like to continue looking for some sort of solution to the core of the problem, as I'd like to get rid of the hardcoded values in the codebase, but also not require a user to remember to add a 'hasDetail' type property to the JSON file. The reason we chose the JSON format is so that non-technical people could still have some understanding of what they're looking at.

With that in mind, I'm going to keep this issue open in the hopes that one day someone smarter than I will figure out a way to have a 'hasDetail' property in the controller for a component, or something, so this is all done automatically.

HOWEVER... @rogerwhite, I love your thought on the compromise in your last comment. It's a great middle-ground. My only request is that in the JSON file the property be called 'tabletSupport' and have a value of 'true', 'false', or not be present at all. (I guess 'supportsTablet' or similar would also work). Submit a pull request and I'll get it in ASAP :)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants