From the view of the admission committee, what if I do not waive the right to access the recommendation letter during my application? Will it affect the chance of admission?
My adviser has already submitted the letter.
Whether or not waiving the right will affect the chance of admission?
Related
I could not think of how to best phrase my question, so what you think I'm asking is probably not what I'm asking. Pretend that I've got three working apps, but the needs of this fourth one are a little different, so I'm asking for advice / best practices, not how to write an SQL statement, code a listview, customize a viewcell, or how to bind to a datamodel. I've got all that.
The TLDR version:
What I need is a sane way to know when the user is done entering his data so I can push it to my server.
I know that there are people out there who have solved this problem, so I'm soliciting your advice. If you also did not want to do a save on every keystroke, I'm especially interested in your recommendations.
Here's the slightly more detailed version:
I'm writing a companion app for part of our desktop software, which uses a proprietary data server to store its data that I can access from the mobile device. In my previous apps, I have a screenful of controls. The user enters/modifies data, and I know to save to my local sqlite table when they exit the screen. It's basically a transactional model, and I only upload the data to our server when they press a button to do so. Works great.
However, for this app, instead of entering a screenful of information, the user is just entering numbers in a list. Think inventory: user has a list of products and quantities, and they update the quantities to match what they've got. The user will not leave the data entry screen often, and is likely to turn off the device, or kick the app out of memory without "going back", so my datamodels can have unstored data.
I have entry fields in a listview. I need to push the entered data to my sqlite table, then on to our proprietary data server. I would have thought to do it from the property setter in my datamodel, but sadly that gets called when the datamodel is initially bound, AND on every keystroke.
I know that there are lots of people who have coded data entry in a listview, I've read all the posts to figure out how make the viewcells work. I am primarily using Entry controls, and I have tried using TextChanged, Completed, and Unfocused. Each one has some sort of issue that makes it an undesirable solution "out of the box". I've got some ideas and know how to solves parts of my problem, but am hoping someone out there has a much better solution than my collection of little hacks.
Obviously there's a ton of details (and complexity) I'm leaving out. I am using a view - viewmodel - model architecture, but am not using MVVM or any similar framework. My solution needs to be in "vanilla" Xamarin Forms.
Thank you so much for your help!
I would comment but I don't have enough reputation, so here it goes.
Is there a specific reason a button can not be added to the page (below the list view), so that the user can press it when they are done taking "inventory"? I'm assuming this is part of the complexity/details you are leaving out.
Without a button, you could make the data save/push happen using an Unfocused event on each entry field. If the user filled in a value for each entry control, the unfocus event could call the method to save the data. The code-behind would get a bit cluttered and it could be messy if you have a long list of entry controls, but it would get the job done until you find (or create) or better way.
Hope this helps.
I've exhausted my search on moodles site and the web-at-large.
I have a need to grant an individual (not a registered/regular user) temporary access to take a course/quiz, capture results and archive actions.
I want to manually enter said user into moodle and assign them a "guest" role so that I can then enrol them into a course and accomplish said goal.
The problem is, when I exercise this, the "guest" can view categories, courses and some other items within the site. I do not want the guest to be able to see ANYTHING but the assigned course (and their grade)...I want to "lock-it-down".
I have been through every permission to the extent of "Prohibiting" everything, however, the guest role is still able to select some items and "peak" into other categories/courses.
Moreover, I don't want them to see the same menu items either...such as Dashboard
If you can point me in the right direction or solve this problem, I will be forever grateful.
Thank you,
Mark
Manually entering said user will make her registered whatsoever, nevermind assigning her a guest role, which is, as I understand, heavily modified by you at this point (best practice here is to create your own copies of role instead of modifying existing ones).
The solution will require code modifications, since role capabilities are not covering everything. However, you may prohibit user to peek into any course(not category) by prohibiting self-enrolments, if it suits your strategy.
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.
I've always assumed that it's risky to identify users in urls within emails. For example, let's say my app is something like eventBrite. I'm inviting a set of users to an upcoming event. I create unique urls for each user's email which allows them to simply click those url's in the email to accept or decline. Ie, they will not have to authenticate with the website.
If they view the email on a mobile device or a public computer through webmail, then clicking the links will fully accept/decline.
Is this approach too risky? I had assumed you should avoid this as something could see those urls and make requests on them which would trigger false accepts/declines.
It'a an opinion but I would assume the link itself can be more secure than the email actually. You can make the accept link valid only through certain period of time (it would not make much sense otherwise anyways).
Moreover, you can make it pretty much arbitrary long. So it's basically arbitrarily hard to guess.
That would leave two options to "see" the link, that I can think of. Physically seeing it by eaves dropping. But you could generate a mail in the html form, which would allow you to hide the full link behind a hyper-ref text. Like Accept / Decline.
There are several parts to this answer:
Is it secure? Absolutely not. It's security through obscurity. You're betting somebody can't guess the link which, as long as it's a finite string then they totally can and as soon as they do, they can RSVP to your event.
Follow up Does it matter? Probably not. I imagine the chances of somebody trying to spoof an RSVP to an event are pretty slim. I absolutely wouldn't protect anything critical this way but if you're just doing something like event RSVP etc (no money changing hands) I don't see anything wrong with this approach. As luk32 said, you can also make the links valid for limited amounts of time etc.
The real issue here, (unless there's something you're not telling us and this is somehow a high value target) is how likely is somebody to accidentally stumble on one of these links and RSVP to an event they aren't going to? You can make the chances of that exceedingly unlikely by generating the links in a sufficiently random manner so that no two links are a like. In this case, I don't think security is the big concern so much as data integrity. That is, is the data you're receiving valid.
I'm exploring a business model that specifies how many times a (costly) function may be invoked per user in an application.
Right now whatever I save, e.g. user defaults, gets deleted when the app is deleted. When the app is reinstalled, the counter is back to zero.
What I need is a way to save information such that deleting the app still leaves the information intact.
I've seen examples that mimic the deprecated unique identifier, but that's per device, which is not what I'm looking for.
KeyChains appear to be the right way to go. I can store a unique ID there specific to the user as well as in the user defaults and that way can track also if the app was reinstalled.