Related
I'm trying to figure out a way to mirror an iPad screen to other iPads. This doesn't seem to be supported on the platform though.
Basically, a teacher would have an iPad, then the students would have iPads and see everything that is happening on the teachers screen, but on their screens.
Thoughts?
I have been attempting to find a solution to this problem myself. I have not found any apps that can mirror exactly what is happening on another IPAD, but some come close.
RabbleBrowser and Ideaflight both had potential. Ideaflight appears to be more for business. RabbleBrowser appears to allow the mirroring, except it only works as a browser and a file/picture mirroring.
Both iPads are linked to the same wifi and when you join a session, they will mirror the iPad that started session. Also allows chat (controlled by session starter).
It does NOT continue to mirror if you move out of browser and into another app however. I had dreams of leading a class through a a lesson on google earth, but no go .:(
Another option is attaching a laptop to a projector. Then you download Airserver on the laptop. Go to the menu bar at bottom of iPad and turn on AirPlay. The laptop will mirror the iPad perfectly and project it! It's wireless and works well. I tried the HDMI connector to laptop but it gives a poor quality, shaky image.
Hope they allow mirroring in future updates. The capability is there, don't know why they don't! Guess trying to sell more appletv!
A similar question was asked on the Apple forum (https://discussions.apple.com/thread/3118281?start=0&tstart=0), and the following app seemed to help them or answer their question.
Have a look at Replicate Pro on the app store:
http://itunes.apple.com/us/app/replicate-pro-for-ipad/id363286515?mt=8
One feature listed in the notes:
Share files between two iPads/iPhones that are running this app. (Pro
version only)
I'm not sure if this will cover multiple devices or simply between two, but it may be worth a look. Sadly, the only way to try would be to spend $5.99.
You'll need to create an application for the student iPad that emulates the screen of the teachers iPad. I would suggest that, although i dont know if its possible, the teacher somehow starts up and app that emulates their entire iPad. Meaning, from within the app named "teacher share" (or whatever it is), they can access the music, settings, notes and other apps found on their ipad. Then that information could be sent over a network to the students.
Nearpod is an app that will allow you to mirror a presentation on several iPads. I have had up to 9 at one time. Through the Nearpod program you can make a presentation similar to PowerPoint, and also incorporate interactive questions, which can be multiple choice, short answer, and even drawings. The only drawback is the full version costs $10/month. The free version is still good, you are just limited on the size of the presentation.
After doing lots of research, I found one app which shares iPhone device into another iPhone device. Really great logic they have applied for screen mirroring.
No idea about detailed how they have implemented but after installing and checking the app I came to know that I think they have used iPhone Screen Recording and broadcasting it on to their server and then on another device they are syncing from the same URL.
OliOli a free and simple screen sharing app for iOS.
iOS App: https://itunes.apple.com/us/app/olioli-screen-sharing/id1382253993?mt=8
WebSite: https://olioli.io/
For the sake of coding itself, I know that I don't need to buy iPhone as there's pretty good emulator.
However, as I will develop iPhone apps for clients (will not have direct contacts to clients) via freelancers sites, do you think that I might get rejected (not chosen) by the contractor because I don't have iPhone at home?
Do contractors accept this way of working:
I develop the app, test it in the emulator and send it to them
They test it in iPhone and send me the list of the bugs
I fix the bugs and send them the app back
They find new bugs and...
Yes, or at least an iPod Touch.
To clarify:
Yes. You really need one. Debugging the kind of errors that cause it not to open on the device at all, for example, can be mind-numbingly tedious if you don't have the device handy.
For most purposes, of course, an iPod Touch should do just fine, but the crux of the matter is that the testers can only test what they see; only the developer can actually test crucial stuff, most of the time.
So to repeat. Yes, you'll need a device. A thousand times yes.
Your client may have something of an issue paying money for software that was never tested on actual hardware. No matter how good an emulator is, you should always try the software on the real machine your program will be running on. The emulator will simulate the way the API responds etc, but you could be blindsided by things such as interference from other running applications, subtle timing bugs, interaction between different versions of the firmware or hardware, etc.
In short, I don't think there is a legal reason you have to test on a real iPhone, but from a Q/C point of view, I think there is no question you need the real hardware to run it on.
Paying customers generally dislike being treated as a beta tester.
I don't think that you won't get the clients - but I do think its a terrible idea not to have a device to test on.
There are many things that won't work properly in the simulator. For instance you can't simulate a camera function, you can't simulate GPS (properly - it always sets you at the apple HQ), you can't simulate sound recording, or test with a real contact address book or a real set up. You can't test whether there is an internet connection or if there are any iphone specific bugs.
On the other side of the coin there are loads of things that will work in the iphone simulator that won't work on the device itself. For instance NSXML and such won't work on an iphone, but WILL work in the simulator.
If you can get hold of one of the new ipod touches they do pretty much most things you will need, and you don't have to get into a data plan or anything. I would suggest AT LEAST getting one of those. You can't make apps if you can't test them properly.
Other things:
In app purchases - #Stephen Darlington
Whenever working for clients, the clients do not pay you for having an iphone or not... or being able to test it on a actual iPhone. The clients pay you for the product you deliver. They expect it to work on the device.
My recommendation is to get yourself an iPhone 3, 3gs and 4 if you want the best results. But, if money is a object here... try developing minor projects which are reliable in the simulator. AND ask friends/family which do have iPhones to test it for you on their device. Its better to ask mates to do this, then ask the client, this way you have a better comunication with your client, your client has more faith in you and... well lets face it, it is the developers responsibility to deliver quality code. Right?
There are some tests you cannot perform in the emulator.
And I am not sure contractors will like this ping-pong test approach (somebody will get tired after couple passes).
You can get an old second-gen iPod touch at a very good price since there are many people who would like to get rid of it. And Apple advices to test apps on older hardware to achieve the best performance. So you'd better get something 'hard' to play with.
Another aspect is performance. The simulator (running on a powerful Mac) will be much faster than a device. This was a huge difference with the original first iPhone.
As an alternative to the iPod: look for a cheap original iPhone on eBay or so. But remember that this will not run iOS4.
If I create an App for the iPhone (OS 3) will it run without modification on an iPod Touch or will I need to create a separate binary? If it is the same runtime, does it just have stubs for the iPhone only features or do you have to check feature by feature using UIDevice to ensure the particular class/method is supported on the device to avoid a crash?
Sorry for the elementary questions, can't find a simple explanation of this anywhere.
Cheers
Dave
EDITED: Based on discussions below:
How can you check if a device supports making calls? At the moment I am assuming if it is an iPod Touch it can't. Is there a way of finding out what shared applications/URL schemes are supported by a device?
You shouldn't really try to guess what the device is. You're far more future-proof if you test for the specific functionality you're trying to use. After all, in the future there might be iPods with cameras. Or compasses (which are on some iPhones but not others).
Since it sounds like all you want to do is see if you can open a URL, why not use -[UIApplication canOpenURL:] ? (This would presumably work on iPod touches that had applications that could handle VOIP -- I don't know if any such exist, but I think it's an example of why you need to test for functionality and not make assumptions based on hardware or OS version.)
The app will run on an iPod touch, no need to compile a separate version. Features that require an iPhone (e.g. camera) will not work, obviously.
What such features do you intend to use? You may provide alternatives for iPod users or alert them that e.g. no camera is available.
This question adresses how to check if a microphone is present: Detecting iPhone iPod touch accessories
Which of the new features are you looking forward to the most in iPhone SDK 3.0?
Is it one of the main advertised six new things, or something smaller? Something in the "1,000 new APIs", perhaps?
Phone to phone communication via bluetooth seems like it will terribly useful for some apps I am writing. No longer do you have to input all the data you want to store yourself, you can share some of it with other iPhone users.
not really a feature, but the best thing about developing the iPhone SDK further is the great frameworks that arise. there are some really, really great frameworks out there already (like the Three20 project) which will become even better with the new 3.0 SDK.
my real excitement will take over once they let us run background processes. maybe in 4.0?
Video! The ability to write decent tools for mobile video uploads is a big draw.
MapKit by far will bring the biggest change sweeping across the app space.
My personal favorite is that we can finally easily track upload progress of large files (like images).
I really, really want to see fixes in the camera API so that it isn't either broken (2.2.1) or forcing a switch to portrait (3.0).
Apart from that, the most useful features to me are:
push notifications. Great for making an app more sticky - you can let the user know that something of interest to them has happened.
CoreData - I've been using a third-party SQL layer, but it's a little buggy and no longer supported.
Peer-peer bluetooth, as the poster above said, is also useful for local data exchange.
And the least useful? Cut and paste. I actually want to disable it in my app (to discourage people from copying content) - and it doesn't look as though you can (yet).
Bluetooth phone-to-phone communication with GameKit will enable a host of currently impossible applications. Multiplayer games with no WiFi network needed and data exchange between two phones are obvious use-cases.
I'd also like to see - not currently included in the betas - a decent camera API that allowed us to customize the appearance of the capture screen, and as another poster said, have it work properly in landscape and portrait mode.
I know there are emulators, but is this good enough? If someone is serious about iPhone development, do they absolutely need an iPhone?
Just my personal opinion: if you're serious it means that you're committed to quality of your product. If you're committed to quality there is no way to deliver a product without actually launching it on the target platform :)
As noted in other posts you'll have tough time testing the multi-touch screen and other aspects of the hardware on your emulator.
Don't forget that most types of iPhone apps also work on the iPod Touch, which is a one time cost and no monthly fees. Even network apps work if the iPod Touch is connected to WiFi.
During development of my first iPhone app, I wrote code that worked fine on the iPhone Simulator, but which did not work on the device. So I would say "Yes, you definitely need to test on an actual device."
The simulator is not an emulator. It is not running the actual iPhone OS; it is running a set of Mac OS X libraries that are very similar, but not identical, to iPhone OS. The simulator is great for debugging and saving time during the code-and-test cycle, so you will use it a lot more than the device, but a device is indispensible.
You really do need to touch-and-feel your app on a real device. A UI that works great while pointing and clicking with a mouse might be terrible when used with thumbs and fingers. If there is any text entry, you need to feel how painful it is to type using the onscreen keyboard, to determine whether it makes sense to provide alternative data-entry methods.
There are also significant performance differences between the simulator and actual devices. You need to test with the oldest (slowest) device you want to support to verify it is not too slow, doesn't run out of memory, etc.
As others have suggested, an iPod Touch is also sufficient, so the cost of a device isn't huge. Also, try to find beta testers with a variety of different models.
Necessary: How the app handles in your hands is critical to something like the iPhone. you cannot tell how it will feel to use when plastered straight in front of you in the emulator on a big screen.
If you cannot hold it you won't be getting the true user experience.
If you need to learn Obj-C, go with the emulator for a while until you learn the ropes and save the expense for later. But yes, eventually you will need an iPhone for final testing. How long you can wait will depend on the features that your app uses, If all you are doing is button presses, you can wait a long time. If you are dragging, using location services, etc., you'll need a device earlier in the development cycle.
Are you trying to convince yourself or your boss? ;-)
I'd say you need one. Emulation of such a new device can only go wrong. Plus don't forget the tactile aspects.
The iPod touch is a reasonable substitute provided you are not using:
GPS, BlueTouch or Camera - the iPod touch doesn't have these
Cellular network - although the iPod touch has WiFi, the latency of a cellular network is way way higher than that of a wifi network. If you are doing anything like designing a custom protocol for your application, you will want to check real-world performance - and if you do this too late in the development cycle, you will be in for an unpleasant surprise.
Whether you develop on the iPod touch or on the iPhone, you absolutely must have a device. This is not optional! The simulator is good, but it is not perfect, and there is no substitute for having a device which correctly indicates performance, screen resolution, brightness, form factor and all the other factors that you will need to consider in your application.
If you buy an iPod touch, you will probably end up getting an iPhone too. I'd just go straight for the iPhone. That way you can use it as your main phone, and get a real feel for how the platform behaves and what an application needs to do to make it great.
Kind-of "yes".
Just download iPhone SDK (it's easy and free) and check out the emulator that is in there. You'll see whether that suits your needs or not. The emulator is not indicative of real hardware performance, there's no touch input, some quirks might be different, some things can not work, etc.
The iPhone Simulator makes it easy to test your applications using the power and convenience of your desktop or laptop computer. Although, your development computer may not simulate complicated touch events, such as multifinger touches, the Simulator lets you perform pinches. To perform a pinch, hold Option while tapping on the Simulator screen.
I'd say it depends on the kind of application you are developing. For a successful iPhone app, one which is properly integrated on the system, you are going to need to be able to test your tactile interface. That's hardly accomplished with the Emulator.
So, my answer is Yes, you do need an iPhone to develop iPhone apps. Fortunately, if you cannot afford one, an iPod Touch (200 bucks) is a very competent replacement. The underlying hardware is pretty much the same.
Necessary. If you plan to develop a successful product it needs to be one the end users (not just the developers) find easy to use.
The best way to do that would be to load your app on an iPhone then take it to various people and ask them to use it while you watch them to see if they experience any issues.
Users can get mighty creative in trying to do things a developer never intended - just ask any support tech.
Unless you're app is going to sell for less then $500 total it's a relatively small investment to build a quality app.
If you are serious about development, an iPhone (or iPod touch) is a must. However, the official SDK comes with a very complete "iPhone simulator". This will allow you getting a feel for Objective C and the entire development workflow. The SDK requires Leopard.
You don't need a Mac for this. You can use OSX86 on your PC, either installed on and booted from disk or through VmWare.
It works. In fact, you can even synch the iPhone through Leopard running in vmWare.
Now, testing on a real iPhone is a necessity because of performance, memory usage etc. Also you need it for the entire authentification procedure, getting the keys etc. (if you want to sell your stuff on the Appstore), testing this really requires an iPhone.
If you buy an iPod touch, you will
probably end up getting an iPhone too.
I'd just go straight for the iPhone.
That way you can use it as your main
phone, and get a real feel for how the
platform behaves and what an
application needs to do to make it
great.
I absolutely agree with this.
If you are seriously developing an iPhone application - for fun or for profit - you will have to run it on a real iPhone to test out compatibility and usability at some point. Since you going to have to get one at some point, you may as well get one now. Don't go for half measures. An iPod Touch may be [significantly] cheaper to start with, but will be money wasted when you go and get your iPhone. (Of course, if you are planning an app that runs on the iPhone as well as the iPod Touch, then you MUST test it on both. You cannot assume that if it is good on one it must be good on the other).
Also, by having an iPhone from day one, you can familiarize yourself with its user interface, its norms and the common metaphors the apps use. That will heavily feed into your own application design process, and make sure that your app looks, feels, and works like a first class iPhone citizen.
From experience developing on other mobile platforms, once you get to a certain point, it really is best to have a physical device to test on. If this is something that you would also be using yourself, if it much easier to get some real world type of testing by using the application out and about.
I also think it helps one to understand the platform better by having the device or devices you are targeting with your app,
if you are going to develop native apps for the iphone, I would say get an iphone or ipod touch to target. emulators are good, but eventually you will need to target the real thing. if you are developing web specific content there are lots of things you can do without it (there are some great dev videos free from apples dev site which will only cost you a sign up) but eventually I would think you would still want to test with the real deal
Get a cheap used iPod touch, develop, get money, buy an iPhone 5.
I'm a nokia dev now, I'm thinking of going to iPhone, Actually I have the Mac to work, just the device itself ;)
I've tried iPhoney and compared to my iPhone (Mark 1) it's not the same, it's close - but not close enough to rely on if the interface is of importance to you.
You absolutely need the real device. The performance difference between the simulator and the actual iPhone/iPod Touch hardware is huge. Code that will run nice and fast in the simulator can easily turn out to be too slow to be usable on the real thing. Also the API provided by the simulator is not 100% identical to the real thing, so code that works fine in the sim, may not work on the device. The only way to know for sure is to test often on the actual device.
As others have mentioned, the iPod touch works well as a development device. So if you don't need any of the features of the iPhone, it's a good, cheaper, alternative.