Jonmat

cropr said:

No, but one can gets skin cancer from the too much sunshine,which is basically the same radiation as the candle light. 

Nevertheless I am not worried.  Radiation from wireless networks is very limited in power: 2 Watt for a mobile phone, 0.1 Watt for wireless router, 80 Watt for a 2G/3G/4G base station.  A microwave emits the same radiation as a mobile phone and is about 1000W.  Luckily it is shielded,  but a leaking microwave might be a much bigger threat to our health.

Mobile networks were first launched in 1990 in the Scandinavia countries. If there was a real danger, we should see this already in the cancer statistics in these countries, even if there is a long incubation period.

Gee, thanks for that information... since you have all the answers, I'll check with you before buying any new tools!  BTW, did you know that the Apple Watch has 10 times the memory as an IBM 370  maimframe of the 1980s... and an infinitely larger display screen?

dick applebaum said:

Jonmat said:

This is why you have laptops and desktops. Gotta pick the right tool for the job.

If that were true, we'd all be using maimframes and crank telephones... or worse!

We've already been down the DRM road and it  largely failed. So much that many countries have laws for digital copies for personal use and a surcharge is applied to all devices with writable memory even if you don't make copies of any media. Trying to directly impede illegal file transfer will ultimately fail. It always has.

The no direct transfer decision also runs into another problem. They take functionality away on the grounds that you might do something illegal with it (piracy). Of course, that is not Apple's or anybody's judgement to make on the users' behalf and makes little sense when what you want to do is simply transfer the photos you have just taken, directly to your friend's phone.

I was unaware that some Android phones lack the file transfer profile.

dick applebaum said:

Soli said:

dick applebaum said:

Soli said:

dick applebaum said:

Soli said:

dick applebaum said:

wizard69 said:

I'm really bummed out with IOS on iPad and would love to see signs that they are becoming more open and supportive on the platform.   I look at it this way, I prefer to have my cell phone locked down hard as reliability is very important.   However that same tight control of the device is a big negative on iPad so I'd like to see Apple change its ways here.    I'm especially interested in port access that doesn't require special hardware to achieve.    The reason here is pretty simple, iPads could easily be recycled into stand alone terminals to communicate tight things like CNC controllers, automation projects or simply projects an an Arduino.

As for Mac OS well that has become my daily way to access the internet (iPad is broken and iPhone is way too slow).    So the obvious thing here is that we see Apple going in the right direction with Safari, maintaining standards compatibility and speed.   Xcode on Mac OS could use an overhaul, I'm thinking a rewrite in Swift with the hope that they kill a lot of bugs by doing so.   Oh speaking of rewrites, ITunes is a mess!

I agree with all of this, especially iOS and the iPad Pro.

IMO, iOS on the iPad should address [at least] 2 levels of users:  the current consumer level;  the pro level.

For example, in education, the Swift Playgrounds iPad app is an excellent vehicle to introduce coding to the masses (consumers).  But to go to the pro level, where the user (developer) is actually writing, testing, maintaining production code -- you need to run Xcode on the iPad -- along with access to the file system, separate kb/cursor, etc.  Apple's HandOff capability would be a real boon as it would allow you to pickup and go, taking your code and IDE with you.

Yeah, and why not enhance iOS to allow the iPad to act as an ad hoc display/kb/trackpad UI for headless computers such as Mac Minis, servers, etc.

Why do you need access to the OS's file system to build an app?

Because a typical app, whether iOS, tvOS, watchOS or macOS, requires lotsa' lotsa'  files -- and you need to manipulate them.

Below is an email I just received from Swift@IBM.com for a simple app to send emails:

If you do the first 3 steps:

1. download the project from Github
2. run swift package generate-xcodeproj
3. open the generated Xcode project

You will get hundreds of files (web server, SMTP server, logger, etc.) and thousands of lines of code:

You see that list of files on the left? That's not your OS's file system, that's Xcode showing you a list of files. You don't need access to `/usr/bin` and other areas of the OS to create a hierarchy of files and folders—this can be down just like the iCloud Drive app on your iOS-based device.

Ahh... But, in order to get to that point (accessing the Xcode project and its associated files) you first need to:

1. download them to somewhere (the file system)
2. access the downloaded file structure to generate the Xcode project

I suppose, you could use a dumbed-down file system ala iOS Pages or iOS Swift Playgrounds -- but that would introduce inconsistencies/confusion between macOS use of Xcode and iOS use of Xcode.

The whole thrust of Swift@IBM is to allow you to write/test/debug/maintain both the client-side and server-side locally -- before deployment.  It is extremely productive to observe both sides of the application at once -- for debugging and implementing changes. The simple mail app involves a web server and an SMTP server -- it could easily involve separate database servers, several IBM Watson servers (translation, analytics, voice to text, etc.).

Here's how the app looks running both ends locally:

[image]

1) All apps have had the ability to store files to somewhere since day one. None of this would be possible if this wasn't the case.

2) All apps have access to any file structure they wish to offer the user. This is why, for example, Finder, by default, hides certain files and folders; yet, it's still an archaic system on macOS users shouldn't have to deal with and that's not required for an app like Xcode that can access a hierarchal file system from within its own app. Same goes for the Dropbox app on iOS.

3) What you need to figure out is how the Mac version of Xcode could possible work with your fingertips as the primary input on a 4" to 13" display when it's hard enough to use the app on a 13" MBP with a mouse pointer and physical keyboard for input, not wonder how Apple will do something that it already does.

Easy!  Add a track pad to the iPad Pro KB/Case and a cursor on the display.  This is for pro iPad Pro users.  I wouldn't attempt to do this using fingertips with an on-screen KB that takes up 1/2 the screen.

I suspect that IBM is pressuring Apple to provide this kind of [iOS-macOS] 'tweener capability for itself and for its IT customers writing/using/extending IBM's MobileFirst apps.