My test action adds a number of devices including lights, fans and scenes which I'd like to make available to all users in the Structure/Home. However, the type of device seems to change how/when it is shared and I can't find any documentation on this.
My first attempt was by linking only one user:
Lights: shared
Fans: shared
Scenes: not shared
I then linked the second user to my action, and found inconsistent behaviour:
Lights: shared
Fans: duplicated
Scenes: "shared" (presumably as each user has their own copy now)
Why are different device types treated differently by HomeGraph?
And where is this documented? Neither the HomeGraph concepts page nor the Scene trait reference page mention this.
In fact, I'm struggling to find any guidance on how to handle multiple users linking to my action from the same household. I get the impression (from the bug tracker/stackoverflow) that we *should not* be thinking about individual users, so why are Scenes scoped to a user that I can't identify!
Related
Ember routing works nicely when working with strict linear paths of resources. However, it's becoming more prevalent in mobile design for apps — such as the Facebook app — to use infinite stacks of multiple interconnected resources:
User starts in the feed.
Presses on a link to a user profile.
Navigates to user's list of friends.
Visits a new user profile.
Goes to any other types of resources such as posts, groups etc.
THEN can navigate all the way back with each page state persisted.
We start off in a known resource - let's say it's Facebook's news feed. In Ember, we'd define that route as:
this.route('feed');
But from there, we'd like to be able to visit any combination of our resources - whilst still maintaining the state of each route. The temptation is to solve the problem through some funky route solution, such as using catch-all route definitions:
{ path: '*' }
But that'd take some heavy path management as discussed here (or perhaps there's some method of utilising Tilde's router.js URL generation?!). But as per the illustrated example above, it would leave us with huge goddamn route paths:
/feed/users/:user_id/friends/users/:user_id/another_resource/:another_resource_id
Not that that's a problem in a mobile app, but I'm not sure if it's the optimal way of achieving this.
So that leads me to consider whether there's some method of dynamically creating outlets as stacks get deeper (akin to modals) - or whether the only way to achieve state persistence is using an app level object, Ember data or an Ember service to track/persist history & state.
Anyway, tl;dr, I'm not desperately needing this functionality - just interested if anyone has a smart insight into how achieve this ...umm ... infinite interconnected nested resource stack thingy.
The answer does not lie in nesting routes in an attempt to prevent them from being torn down.
Instead the answer lies in state management.
Browser history can be used to manage URLs and bound to the back buttons on each page in our stack. However, restoring the exact state of the page (including scroll position, especially when models may be lazy loaded) requires some additional design.
The easiest method of doing it is using the ember-state-services addon.
In particular, this video by Travis Hoover from Oct '15 was really helpful. It explains how ember-state-services creates 'buckets' for different model instances.
So, when navigating through our Facebook stack, the state of each page can easily be stored & restored even if we visit pages which reference the same route/controller. In our example, it helps with preserving the state of the two user profiles we navigate to (user/:user_id).
So, for storing each user profile pages' scroll positions, get the scroll offset from your scrolling div/component and use ember-state-services as so:
// app/controllers/feed
scrollPos: stateFor('scrollPos', 'model')
// app/routes/feed
saveScrollPos: Ember.on('deactivate', () =>
this.set('scrollPos', scrollValue);
));
It'll store your last scroll positions on users/1 AND users/2 separately because state is bound to the particular user models.
The only gotcha I can foresee is if the user was to visit the exact same route multiple times in one stack, but there's not many use cases where that would be a problem.
This is my first Cordova/Backbone application.
I have grasped the whole deal with Models, Views, etc. somewhat, and now I have gotten to actually making proper view structure for my app.
It is a user centered app, which means that views are dynamic depending on who the user is and their status in the app.
Could you please help me to understand what is a better choice: making one (large-ish) api call to the server to get the data for all user-related app views (that would get all user info, various menus for the current user etc) and put them in one User model or make several smaller api calls that each get a fragment of the information (let's say, profile information, newsfeed information and options for two menus, so 4 ajax calls total) and keep the models separate? All the relevant views (UserProfile, SideMenu, UserProfileMenu and ActivityFeed) are rendered on user login. Some of them are available for user at all times (SideBar menu for example), some get switched out as user navigates elsewhere.
I design the server-side API myself, so I can freely choose what data is returned and when.
"it depends". If you need all the info (from 4 ajax calls) from start, it would be better to create one big api call, because callig server 4 times will last longer than one big call - 4x server ping time. you could use the big call on app start and still create the 4smaller ones to refresh data when needed.
I have a Facebook application that wants to publish document reads to a user's OpenGraph.
Since read is a reserved, built-in action, my objects have to have the type article. The publishing of reads to the user's graph works fine and the last read is also shown on the user's timeline.
Additionally, I have set up some aggregators that would show the last 5 reads, the most popular authors etc. The problem is that I can not find those aggregators anywhere in my timeline/profile or in the App section of my user.
Is it not possible to control/show the aggregators for built-in actions and objects?
I have a feeling it should be, since I can set them up and (for example) Spotifiy also uses the built-in music.song objects, as shown below - this is basically, what I also want.
All I am seeing on my app's timeline section, though, is this:
I believe you are not in control of when facebook displays your aggregations as you have defined them in your open graph settings, since facebook uses the so called 'GraphRank' to determine whether to show your aggregation or not. The calculation goes like this:
GraphRank = affinity * weight * interactions * time
affinity (score): this is the relationship between the viewing user and the creator of the action.
weight: if two users interact frequently with each other, the respective actions in the open graph are rated higher than for users who do not have the same interest and are not in close contact on Facebook.
interactions: how often does the user interact with the application and how do friends react to the activities in the social channels (if nobody clicks on the published actions it's bad for the GraphRank).
time: if an app is used irregularly or only once, actions will receive less attention in the long run and will be presented less prominently on the timeline.
See this article: http://www.insidefacebook.com/2011/12/27/edgerank-and-graph-rank-defined/
This is not the perfect answer to the actual question but I was able to solve the problem nevertheless. In case someone else is in the same spot, you might profit from my learnings:
The application I'm building wants to push read actions to a user's OpenGraph. My aggregation problem was that my reads from the built-in news.reads action did not get aggregated. To this day, I do not know why not.
Instead, I managed to create my own read action. It is not connected to the built-in one and exists in my own namespace.
This action can now be connected to my own objects as well and is not bound to the article object – as is the built-in one.
Having my own actions and objects, it was a breeze to follow the instructions for aggregations and create as many aggregations as I like. They also actually show up in my test users' profiles. Yeah.
Let me preface this by saying that I know the ContactCenter sample is just a sample and that the application sharing extension classes it exposes are not officially supported.
With that said, I've found several limitations to the ContactCenter sample's application sharing functionality.
Namely:
1) After the caller shares their screen with the agent, the agent cannot take control of the caller's screen. There is no error, but the request for control just kind of happens with no result, even if the customer has set the session to accept all requests for control
2) Prior to the caller sharing their screen, the only participant in the conference they can see is the contact center attendant. As soon as the agent accepts the sharing session, the agent's identity is revealed in the caller's participant list.
3) If the caller shares their screen, closes the sharing session, then starts a new one, this new sharing session comes into the agent as a seperate conversation, in its own window with its own toast message, etc.
I have plenty of theories as to why these limitations exist and possible workarounds, but before pursuing them too aggressively, wanted to see if anybody else had workarounds OR just as usefully, if the UCMA team is confident that these are just inherent limitations to UCMA.
Any info would be appreciated.
My colleague and I found some answers, which he posted about at: http://blog.greenl.ee/2012/02/06/handling-application-sharing-calls-ucma/
The short version is that if you separate the application sharing call into another conversation and back to back it, you can get some good, basic functionality going.
So as to avoid overwhelming the infrastructure in a web application instance, what would be the methods of implementing a feature roll out to a controlled group of your user-base?
It depends on the situation. You can't really redirect them to another site using another database if the users are expecting to work with real data and the real site.
I would introduce a flag on your users in your user-table, let's say isBetaUser (bool). Then you can just show these new features for users that got this flag set to True. You could also let them check this flag off using a checkbox through some settings page, if they don't like the idea of trying out new features that is.
Partition your users into groups. Randomly. Demographically. Somehow.
Pick one or more groups for a pilot.
Fix your web site to have both versions of your app running. Maybe use virtual hosting or a different path or something.
One database. Two applications. Data doesn't move. Only the presentation changes.
At first, all users are in the old version. Workload has not changed.
Move a group of users so that their default URL's or links or menus or whatever are references to the new application.
Same workload. Same database. Same number of users. Two applications.
Move another group of users to the new application.
Same workload. Same database. Same number of users. Two applications.
Eventually, after all users are moved, you can delete the old application.