Since I'm not even sure where and how to start solving my issue I will appreciate every smallest push to the right direction.
So, I need to write an iOS application that would keep track on some events of any or at least some webkit-based browsers, or even integrate my app's "Open with..." item into a browser's context menu.
Is it at least possible?
P.S. yeap, since there's no way to use browser extensions in iOS, I'm trying to find workarounds without need to implement my own browser but rather tiny 3-rd side application working along with some of existing browsers.
Related
So here's the situation. I am using a third party digital document signing service called PandaDoc in my mobile application which is built on PhoneGap/Cordova and I am not able to change any of the input, text-type fields when attempting to do this via the mobile app on an iPhone (haven't tested Android yet).
Here are some things i noted about this:
1) When viewed online in Chrome (on my laptop) or on my phone in the Chrome browser everything works fine.
2) The only form elements that aren't working on mobile are the input (type=text) ones. The checkboxes work, the dropdowns work etc...
3) I don't know much about Angular.js but i can tell this third party app was built on it. When i inspect and compare the mobile vs web version i noticed that on the mobile version the input fields have these two directives:
ng-pristine and ng-touched
From what i can tell researching these, they seem to be mutually exclusive so not sure how that would affect things. Also the web version had:
ng-dirty and ng-valid-parse
both of which the mobile version did not have.
I know it would be best if i could post some code here but i don't know where to start. In my app there is just a simple embed script that puts the PandaDoc into an iFrame.
If you want to see the mobile test version of this app you can view it at http://dev.velexo.com/m2 I have a test user with a username of "mobile2" and the password is "pass". Unfortunately there is no easy way to send out the iphone app version of this and that is where the problem is.
Oh also, when you log into the application, click on the W9 Information button and then the Enter Your W9 button, this is what brings up the pandadoc
Also should have mentioned I'm using JQuery Mobile in the app.
Any advice/guidance would be welcome even if it's just a guess.
just looking over my old questions here. The answer to the actual question I asked is that you can not change anything in an iFrame from the parent frame unless both the domain and the port match due to the cross-domain policy restraints.
There are no ways around this that I am aware of.
The solution to my particular problem was to get rid of PandaDoc entirely because it just wasn't designed to be used on a mobile device. In the end i wrote my own javascript for creating a signature and passing to the backend where i used a php pdf generating library to construct the final document.
I was wondering if anyone (possibly Adobe/Aviary) could clarify something for us. Our startup is looking at an photo enhancer/editor - and I'm curious about the Adobe Image Editor UI, but was quite put off by making users have and Adobe account and having to log in. I have looked at all the documentation, sample code and it all points to the "Integrating the Authentication Component" here https://creativesdk.adobe.com/docs/ios/#/articles/gettingstarted/index.html. Is not the client-id/client-secret enough to know the billing scenario for us?
In fact, even ONE external login would kill user experience for our offering.I understand that the Cloud components would require separate logins, but we just want Image Editor UI, nothing else (and willing to pay for this obviously).
What I want to know is, would the users of our app have to login and manage login state (with adobe) every time they want to use the Image Editor? If anyone could point me to the right documentation it would be great. I plan to write the wrappers for React Native once I can confirm this (yes, I'll open source it as well once I'm done).
Thanks
No need any user login.
You see this login screen since you are in DEVELOPMENT MODE, in release mode you won't see this.
To see how it's really works on production (release) mode, see some app that using this image editor.
Does anyone have any ideas how I could package an external interactive slide that could be dynamically loaded by an iOS app? Is it at all possible?
e.g. Imagine having a presentation app on an iPad. There is a set of interactive slides held on the web somewhere, let's say they contain draggable elements.
Can I load one of these slide objects into the app and interact with it? If so, what format would the slide object be?
Thanks,
Mark
Technically it's possible to dynamically load bundles (NSBundle) components in an app. These bundles could even contain executable code, though AppStore guidelines prohibit use of dynamically loaded NSBundles in this way for security reasons.
Additionally you could just use a UIWebView to display some 'slides' on a webpage, though it will be very hard to make the app behave as if it's the same as the native slides - perhaps even impossible (due to how rendering of webpages work compared to native controls, for example).
Ok so lets say you have these "external interactive slides" on a web server somehow. Since you are not saying they are of a certain type (like powerpoint or such) I will just assume that these slides are of some rare format that is probably not supported by any existing apps or the Safari browser.
Then the answer to your question would be: Write your own iOS-app that can read, present and edit these slides. What format are they? Well it doesn't matter. Write an app that can download the slide data from the data and parse it, and present it on the phone.
Then let the user interact with it, and perhaps make the app upload the changes to the server.
You can do anything you like in your app, there are no limits. You just have to write the code for it. If there was some kind of standardised format, lets say you wanted your app to show powerpoint presentations, then you would have 3 choices. Use someone else´s app, or write your own app with a parser for the powerpoint files or make your own app that use some code that someone else wrote to do it (a third part library that you include in your app)
In your specific case, I can not tell if there are any third part librarys to interact with your slides, but my guess is that you will need to do most of it on your own. You could start with looking at how the web services that interact with the slides online works, and if you can interact with them from an iOS-app that you make yourself.
There is nothing stopping you from creating an app, read the slide data into the app, present it in any way you like, let the user change it, save it in your app, or upload the changes to a server. It's all up to you =)
Good luck!
Can you tell me if Apple accepts an application that opens an embedded browser with most of the functionality living on a web application on the internet?
I have read contradicting opinions on this, and I have even seen several apps that seem to use an embedded browser for the main functionality of the app. Still I couldn't confirm this.
This way we could correct problems on the application functionality on the server with no need to submit another version of the app, while keeping the ease of release through the app store and the home screen shortcut.
Thanks!
I can't get the exact quote from the guidelines, but I know that Cordova apps are allowed, and updating the web files dynamically without going through a new native app version is also allowed, as long as:
* The updated code runs with the Safari Webkit engine (true for Cordova)
* The main functionality of the app is not changed
You say this is a bad idea because the user can save a bookmark on their home screen. This doesn't seem to me like a reason for something being a bad idea to me. If this is the only drawback then I would say go ahead and do it. Why should I care if someone wants to bookmark to my site? The app will not work very well outside the app anyway. If you have an actual logical reason why this is a bad idea instead of some emotional response then please bring it up.
I am doing this too in my application. I am under the impression that as long as you are pointing to a secure site then it should be okay. Please enlighten me: is there some good reason why Apple forces people to develop applications the hard way? A web application is hard enough without having to deal with some monolithic organisation imposing ridiculous rules on you.
Most sites are either fully released, or in beta.
But what happens if you have a large site, and some of the parts are still in Beta, and other parts aren't.
How do you effectively communicate this to the customer?
Maybe take a look at how Facebook, Bloglines, Gmail did it?
Like "We have this beta thing going on, come on over and see the same site with new stuff, but if it doesnt work, use the old parts"
Maybe gmail labs where you can sign up for "beta features"
If there's a certain way you enter the part of the beta site, maybe you can have a modal that pops up that they have to agree to every time. I wouldn't have it on every page since it gets annoying, so I would only use this approach if there is a definitive way to get into that part of the site (e.g. people won't be coming to random parts of the beta section through Google or something).
One way I've used for non-web software is a change to background. So for example if your normal site tended to have a plain white background, you could have the beta site have a repeating beta text in a background image. You want to make it fairly faint so it is present but doesn't detract from the overall experience.
Another subtle but present option would just be to change the title bar.
Or you could do what google does, which is a large site with some of it in beta. Check out Google experimental search. Basically the site is no different, but it is hard to get to accidentally.
There are a few ways.
Provide access to the site via two domains (e.g. www.domain.com and beta.domain.com) and only allow access to beta parts of the site when going in via beta.domain.com.
People will be accessing the same code base, but will only get access to the beta sections if they've specified the beta subdomain. Trying to access beta sections of the site will explain this & tell them how to access the beta.
Strongly Flag the beta sections of the application as being beta, and force the user to acknowledge that they're OK using beta features with some kind of agreement screen. The first time they try to use the beta feature, they'll be shown the agreement screen. Subsequent uses of the feature will prominently deisplay that "thios part of the site is in beta and is used at your own peril."