I was wondering how I would go about updating my passes. I already know I need a webServiceURL (which I assume will be your IP address or one set on Ruby on Rails or something) and an authentication token. I'm more focused on how I would actually, physically update it. Is there an easy way out of this? Sort of like those iPhone app creating websites (but you don't professionally code it). I'm going to look into it more, but there aren't too many resources on the internet to choose from (that are useful).
If you are looking for a WYSIWYG, point and click solution, you might want to check out our service PassKit.
To see how updates work, you can start with this demo pass, flip it over and push yourself an update. You can import the template for the demo direct into the pass creator, edit it, and be pushing updates to your own passes within 5 minutes.
We also have a fully functional API that allows your to update and push a new pass your pass in a single call, E.g.
https://api.passkit.com/v1/pass/update/template/yourTemplateName/serial/yourPassSerial/push/?field_value1=newValue&field_value2=newValue2
If you want some code to get you stated, you can also access the source code to our pass creation pages.
If you are going to roll your own, I would use passbook-ios or something like that which is a Ruby Gem. If you want to use a service Urban Airship has one....though the pricing is a bit expensive at 10 cents a pass.
Lance
Related
I have a web application with Rails 4 where you have to log in to use it. Now I want a demo version of this app. By demo version I mean a version that has all the features of the original app but without the login. And all the demo data should (and can easyliy) be deleted from time to time (either automatically or manually).
With the original app up and running I want to implement the demo version with the least effort. Ideally I can use most of the original code without any changes. But changes to the original code on the other hand will be available in the demo version without any extra work.
My first idea was to implement the demo version just in the cache/session so if the session is expired, the data is deleteded as well. I canceled that idea due to the deep integration of ActiveRecord in the original app. I would have to re-code all the demo classes and/or build some abstract parent classes and so on.
The second idea was to simply use the original app but to add a flag to each demo account so that they can be distiguished from all the regular ones. I hesitate with this idea because I'm afraid to blow up my database (i.e. the tables that I use for the original app) with demo data leading to lower performance and higher cost/risk of wrong interpretations when evaluating the app data (e.g. how many accounts where created yesterday).
Do you have any ideas how to realize such a demo version in an elegant way?
Smart approaches welcome!
You can have a Guest user account, and a before action in ApplicationController that checks if the current application is in demo mode (specifiable through a custom config) and automatically logs in the user.
You can use a cron job to delete the demo data. Whenever is a good solution for managing cron jobs in ruby.
for automated fake data creating use whenever and faker gems. Faker will generate fake data. Whenever for cron job. And after every demo session it will clear the mock data.
take these point : session, cron, fake seed data
I currently work at a school and have an idea to create an app that allows students to contact a grown up (for example, the principle) anonymously through an app. The app would quite simply consist of a contact form. I am trying to find out the best, and easiest way to achieve this without setting up servers with a separate API. Does anyone have a suggestion on how to achieve it? Is there any way to set up an e-mail form with a pre set recipient and a built in sender-account? Please guide me in the right direction.
You would need to implement an SMTP client. You can use open source code like skpsmtpmessage
It's likely that their example app could be your solution.
Your biggest problem will be the deployment. You definitely need to pay an $99/y developer account and add all the students device ID's to your account (with a maximum of 100 devices/y) or register all of them as beta tester (I don't know the limitations).
Probably this isn't doable so easily, as it seems you don't have iOS developing experience so far. Maybe you can find something on the app store that works with self hosted databases. But you definitely need to host some kind of webApp/API.
You may want to give Appygram a try to handle the back-end if you are able to set up the contact form itself. While it's a separate hosted API, at least you don't have to build/manage it.
Appygram is a free web service that would allow you to configure all the details such as which adults could be contacted, their point(s) of contact (i.e. email address), and it would process and send all the submissions for you. All your app needs to do is send a form post request.
A nice thing about having this information outside of the iOS app itself is that you can change the contact details on the fly without requiring an update to the iOS app itself. Whether you use Appygram (which, since I contribute to it, I am slightly biased toward!) or something similar, I would say that since this is for students, I would recommend a solution that would allow you to update your configuration without requiring app updates.
Finally, I'd second what Julian said. The challenge here could be with deployment. One possible alternative would be to make this a mobile-friendly web page accessible only via student login or on the school network (or both). Would probably be easier development-wise and wouldn't require installs nor the hurdles that Julian described with device registration, etc. And, Appygram would still work with this setup as well.
Good luck!
I am developing something with ejabberd server. I came to the need of changing the subscription logic. I am using ejabberd-2.1.11
My need is on how the subscription works, I would like to change the logic so that users upload their roster contact with subscription both automatically and and save in in the rosterusers table-colum subscription immediately to be B. So that they should be able to see online and in their contacts at least when the first one has already registered to the server. ( hope this make sense for you and is valid)
I am a very beginner in erlang and ejabberd architecture but I have already developed some basic modules, my question to you is if you could help me on this regard, how difficult is to make this change and if you could give me some hints where the changes would be
I'd stay away from modifying the server, it conforms to standards and follows the specification. So if you ever need to move to another server or upgrade, you know it's just going to work.
What you would do to achieve this is implement this behavior on the client using the server's features.
If you are really sure you want to modify the server, mod_roster.erl is the file you want to be looking at.
If using an external DB, you can also modify the DB directly, but changes won't be reflected until the clients log back in.
It's quite common in sites- you have a "demo" version with a guest account full of data/posts/comments that you can play with, and all the data is reset every few hours so users wont spam the demo site.
I thought to have another rails environment, "mysite_demo" and use a cron job to call rake to reset it's database every X hours, and populate the seed data.
Then it hit me that all over my app I'll have to check if I'm running in "demo-mode":
For example, if the demo site has a login/register page too, a user might register, insert some data and wonder why his account is deleted after he logged in again.. so demosite shouldn't have a register option at all.
So I thought I'll make a "demo" branch of the code.. with the difference and just merge changes as I go... sounds like an overkill.
ideas?
In my application I started with a fixed demo user with an account that resets every hour. Something about that model didn't quite sit right - if there were multiple users hitting the demo at the same time you could get into some weird concurrency issues. And what if a user is in the middle of a demo and your reset the demo account? What happens?
I don't know if this model works for you but I ended up creating a brand new user account with a demo flag set in the database - I also automatically log the user in. This way the user gets to play around for as long as they like and I don't have to worry about data getting deleted/changed while a user demos my app. I run a cron job every night that deletes users with the demo flag set that are older than 24 hours.
If the demo version is running from its own database, how is it any different from the real thing? The demo site is just an instance of your product.
Just clean up the DB and redeploy the demo as needed. Is it just this simple or am I missing something?
Then it hit me that all over my app I'll have to check if I'm running in "demo-mode" (e.g, you cant register a new user in the demo) and make the site behave accordingly.
If the site is in demo, why does it matter what the users do? Anything they do will be wiped in a few hours, so they won't be able to actually do work with it.
It sounds like you are trying to handicap the site so they will pay. I don't know what your site does, but if its a host based service(web page that stores & display information) then the limited life span of the data should deter squatters.
If you website does something that can be used elsewhere, then I can see limiting it. An example might be a service that transforms media formats, or writes resumes. If the user can do something useful in the 2 hour window and walk away with it, then you might consider branching.
Why not allow the user to make an account even if it is deleted in an hour?
That allows them to see how the registration process of the script works for at least an hour, maybe give a message on the signup page that the account is only valid for an hour.
Just my thoughts
Is there any other functionality that is different in the demo version than the production environment? If it is just an issue of making the user register, you could just create a registered demo account in production, and give out the user name/password for people. Although this may not be an option depending on other business requirements.
If you are willing to use Authlogic you can take a look at this, then every X hours you can look through the database for users that start with anonymous_ and delete records that are associated with them.
Just make a separate demo site that works exactly like the production one, but the DB gets reset once an hour to clean example data. The only change you need to make is a banner across the top of every page that says its a demo. There are several ways to do it, (modify your site theme, or maybe use frames) but basically you should only have to change the code in one place, instead of throughout the site.
You could setup a new environment demo on your database.yml, with read-only privileges for the User table, and an additional demo_database. Then place some checks on your code to see if your RAILS_ENV is on DEMO.
That way, you only need to work with the same codebase and just show whatever you feel like it.
You can deploy it as a separate app with its own database to a separate domain or subdomain and then check the domain to decide what options should be available. For instance if you put it on demo.example.com you would use:
if request.domain =~ /demo/
If you use Capistrano you can set it up to update both apps when you deploy so they are in sync.
I'm trying to develop an application which modifies a couple of tasks of the famous Online-TODO List RememberTheMilk (rememberthemilk.com) using the REST API.
Unfortunately the modifying takes a lot of time, so I want to give a feedback to the users.
My idea was just to display a couple of text lines (e.g. modifying task 1 of n...).
Therefore I used the periodically_call_remote on my page and called a which reads a Singleton.
In the request I store the text that should be displayed in the same singleton. But I found out, that once I set up a request, the periodically_call_remote does not update the specified div.
My question to this:
1. is this a good way to implement this behaviour?
2. if it is, how do get the periodically_call_remote to work during a submit?
Using a Singleton is most definitely a bad idea. In an advanced production setup it isn't guaranteed that subsequent requests will go to the same process or to the same machine (and subsequently will have a different Singleton). Plus, if you have many users, I don't even want to think about what'll happen to those poor Singletons.
Does any of this stuff actually need to go through your Rails app? It seems like you can call the RTM API via Javascript from the page the user is on and then update the page when the XHR request is complete.