-
Notifications
You must be signed in to change notification settings - Fork 85
Find a better way to determine if view is a tablet #126
Comments
Reference line ~488 in core.js ? |
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. |
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.
ADD "hasDetail" : true to all components that have detail views. Example below.
ADD NEW LINE AFTER line ~486 NEW LINE
THEN REPLACE line ~490
WITH
|
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, (Sent from my iPhone)
|
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. |
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:
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? |
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 :) |
Reference line ~392 in core.js (look for the TODO).
The text was updated successfully, but these errors were encountered: