List view in calendar
I'm so glad they reinstated that in ios7.1. The calendar app was almost completely unusable without it.
40 publicly visible posts • joined 28 May 2007
GIF supports custom data blocks so you can easily embed extra information into the file without breaking other readers.
GIF allows you to build up changes ontop of a previous image so is naturally quite suited to this sort of application. Though it's still limited to 256 colours
This feature is almost hidden. But when you select open from word and chose a supposedly corrupted file from the file selector. Notice how the open button has a drop down menu which has "Open and repair". I've not met a corrupt document which i've not been able to salvage with this option.
It's clearly unfeasable for a wide reaching app store to expect all applications to run on every phone.But there is a clear need for a simple way for users to be united with applications that work well with their phone.
Creating standard APIs just hasn't worked. For instance, just writing in JavaMe is not good enough - a good app store will have empoyed someone to actually verify the apps for a whole a range of phones and only offer the the app to users of the phones that have been verified. Its unreasonable to ask developers to test on every different combination.
Though we can have a dig at apple for many things, their exclusivity and proprierary nature makes for a much simpler developer and user experience.
There has been a long running problem of inadvertent intrathecal injection of vincristine by medical staff. This is a chemotherapy drug which should be injected intravenously, but as it's often accompanied by another drug which is injected into the spine - they are sometimes mixed up, with fatal consequences (vincrustine in the spine usually kills within 48 hours, or irreversibly paralyses patients).
Although awareness, training and clear packaging helps, the most effective solution is probably to change the caps for intrathecal and IV so that they not compatible. This simple mechanical change of plastic connector would seem cost effective and obvious yet the NHS rollout seems to have dragged on for many years. I can't imagine anything that relies on IP network getting cleared before 2050
http://www.google.co.uk/url?sa=t&source=web&ct=res&cd=2&ved=0CAoQFjAB&url=http%3A%2F%2Fwww.datix.co.uk%2Findex.php%3Faid%3D181%26lan%3Den&ei=QkQzS4ybMZOj4QadqqGqCA&usg=AFQjCNEUiOu3APa8bU8_fMAWiNnA7ZjTtA&sig2=r-nkUD9uZcPJHme3KasKuA
yes, it's the "Cymraeg version" - get your soft mutations correct.
I know its hard for people who rarely stray from the narrow stereotypes, but many in Wales prefer to talk to each other in Welsh. My mother and her sisters/friends regularly text each other in welsh and have to rely on multitap and a welsh dictionary that they have accumulated throughout the lifetime of the phone - which is instantly wiped when they upgrade.
The main issue is with technical support when you get some really bad translation of an error code. Technical terms really don't translate very well into welsh and you need to be skilful with the dialect and savvy with the technology to know when to leave a term alone.
If "bluetooth is not switched on" is translated to "mae dannedd las heb ei droi arno", then I think i'd rather have the english thanks!
As to the whole 3 different languages in wales. They are very minor regional differences, and when written down mostly relating to different vocabulary of common words.
>> reasonable argument against doing any native Symbian development at all
Most people I talk to who have used JavaME in anger have come to the conclusion that it's a bit of a toy language with so many bugs in the native interfaces that it has probably wasted millions of man hours of development time with projects starting in JavaME and then being re-written in C++ because the limitations/bugs could not be worked around.
I found 4 crippling memory leaks which would mean an application running in the background could not last for more than a few hours.
The HTTP support is atrocious with no timeout, no ability to cancel a request. And even simple things like fetching IMEI/IMSI or battery charge state are "banned" for 3rd parties. The official line is that you should write a C++ deamon which talks over a local socket to the java code but this is unproven and buggy :
- doesn't work in flight mode on some devices
- Packaging a JAR and a SIS file together is really messy since you may need both symbian singed and java certificates.
- Who knows if symbian signed would pass the above.
If a large % of developers are doing the above just to get the IMSI, creating really unstable apps along the way,then it doesn't make sense to close it off.
The big hope with the new java code is that it should be updatable OTA which means that if nokia are responsive, there might be a chance that commercial/enterprise grade sw will be feasible on java mobile. That is as long as the operators keep away from the security model
.
As for the question of UI. Nokia now own Qt which sort of already working on S60 devices (that includes PC style menus, buttons and other standard controls).
I think you have to approach these sort of ideas with an open mind. e.g What if the Symbian foundation adopts a Linux Kernel and Symbian becomes a Nokia sponsored Linux distro?
What if the from the group up asynchronous nature of Symbian makes it a better choice than linux for low power and SMP hardware - to the point where it makes sense to deploy it in a netbook type device which provides 3G web browsing a basic productivity suite.
I don't think the intention is to run Symbian on any old laptop and support a myriad of generic hardware peripherals. I think it's more a recognisation that the cheap netbook market is a growing one.
Nokia PCSuite is a bit of an abomination, but if Nokia is serious about being a service company then it needs something like iTunes running on Windows, mac and linux.
Remember that PCSuite currently does sync, backup, messaging, photo sharing, music upload etc. It represents quite a big investment.
Also, any large software company creates development tools throughout the organisation, so you might have tools running on windows to calibrate phones, get crash dump info from the phones etc, I'm sure Nokia networks have good uses for a windows based toolkit also.
And other thoughts: Maybe the trolltech UI designer tools for mobile need to run on windows also.
I don't think moto are seriously going to allow the user to switch between OSes on the fly (the royalties would be crippling).
Virtualisation has been in use in mobiles for a long time. But it's trendy right now innt.
Many 3G solutions on the market are 2 chip - that is one chip for the RTOS(e.g nucleus) and one for the Applications OS (Symbian/Ms mobile/linux).
Now obviously 2 chips are more expensive than one, and so there is a BOM cost penalty. However the effort to port the signaling stack to 3 different OSes is really astronomical.
So one solution is to to virtualise the device. That is, presenting the ARM chip to two OSes, with a Hypervisor taking care of OS context switches and message passing.
This means you can :
- use the same RTOS (which has gone through type approval) with any application OS you fancy *on the same chip*
- have one team responsible for the whole 3G stack delivery to all phones in an organisation (no expensive ports)
- isolate and test the signaling stack as a black box. (No need to worry about mixing 3g and application threads)
- Create better seperation so that you can produce 3G/EDGE versions
- Increase security since the RTOS can have a different memory region and is closed to 3rd party applications
- Ease RT performance - you can verify RTOS deterministically since you are not tweaking priorities of *all* threads in your system each time you add a new feature.
Bear in mind that before Montavista released its Real time patches to the linux kernel, this technique was the only way of doing single chip handsets on linux.
One other good reason for virtualisation is compatibility. Having the freedom to deploy a completely new OS, but retain compatibility with old applications (simply by including the old OS ROM on storage). With mobiles shipping with a few GB of NAND, storage space is becoming less of an issue (a typical phone ROM is ~128MB)
Until just over a year ago, I had never paid for a mobile phone bill in my life. Working for a telecoms company since graduation meant that I was probably the worst person to answer my friend's and families questions of "what's the cheapest phone deal".
After around 8 years of free phone bills, early access to GPRS and 3G phones, I grew accustomed to having my email at hand, streaming video and maps and silly questions anwered instantly.
When I started paying my own bills, I started with the most basic pay as you go for a few months to see what my usage patterns were and which luxuries I missed the most. I settled for a deal with cheap phone calls, free mins and text - and a 250mb monthly data tariff for just a few extra quid a month.
The zero cost argument, is obviously what subsididers and advert brokers rely on to lower the barriers to mass uptake.
But DVB-H, like digital radio are not 'Phormable' and so not currently attractive to the emerging subsidy models. Never has there been a more personal billboard as a mobile - an item that you check for after wallet, keys before leaving the house.
MMS - they got it half right. People take photos of their exploits on night out all the time, but they are more likely to email them when the get back home, or add them to a facebook group - but operators can't make money out of that.
I think you will see a growing number of people uploading direct from phones as the handsets are replaced over the next year or so.
In general, the mobile market have worked on the segmentation principle. The majority of the users will use mobiles for phone calls, text and 1 other significant service.
The other 1 service is rarely fixed and might be music player, camera, mobile web, games etc.
The revenue from these other services is pretty small, and I don't see the problem with exploring mobile TV as a way of increasing ARPU if there is a genuine consumer demand for a service.
Mobile TV has had a fair amount of market research in both europe and asia, which showed positive results in terms of how much punters would pay for mobileTV.
However, at the time of the studies I had doubts about the ecological validity of the studies.
With rolling news a vapid, content free - like a fart delivered in an important looking envelope. I can't really see the urgency for live content (see world cup Germany for lackluster response to mobile sports).
I don't have a TV at the moment. I use a 3G card and a laptop - i tend to download in full and store a fair bit of content for when I'm traveling (that is hotels - I like reading books on trains). The iPlayer complements my life style rather well.
Wouldn't it be easier to set up snapshots of virtualised machines with all the different anti virus software installed. You can then keep trying a virus and replaying the antivirus software's response until it's cracked. Being able to single step through the kernel side portion of the AV solution must make it easier to foil.
That's the point of the article though, it's nothing to do with the father's DNA and chance.
Mitochondrial DNA always comes from the mother and does not have a chance to be paired with the father's DNA.
This yields two concequences:
1. If a mother has a disease linked to mitochondrial DNA then the child is 100% sure of having it, since the egg's mitochondia IS the mothers
2. m-DNA doesn't mutate via sex, the disease will not 'bred' out of the population - it ranomly mutates at a much slower rate
The reason this is significant is that m-DNA doesn't alter the charaterastics of the person (in terms of looks, build, eye colur). And so man has crafted a way of ensuring the survival of the mother's defining genes, inspite of a faulty (hard to repair through natural selection) mechanism.
>>so you could remove or add 'gay' DNA
No - there's no such thing as gay mitochondria
I always thought it was a bit unfair that the mother gets to donate half their primary genes but all their mitochondrial DNA. (The sperm needs a lot of mitochondria to propel its little tail but jettisons it as it fuses with the egg).
I suppose it's sweetener for having to lug a foetus for 9 months.
Anyway, it's useful for tracing ancestry which will be broken in this case.
Constant re-writing of the page file may(depending on use cases) wear the NAND prematurely aging the phone and cause relocation of the page file all over the chip which will may eventually cause the device to behave like a jellyfish swimming through treacle.
So for mobile, one way paging of code may prove a lot more sensible than your "virtual memory".
I'm not sure how big the problem of wearing from a user perspective.
It can be demonstrated by mounting a swap file on a MMC card on a Nokia770 or N800 (Linux based).
Some users report excessive wearing after a few months, but other are fine 6 months + on. There are many variable though, for instance if your file system updates the modified date of each file each time it accesses it, then that can also cause excessive writes over time.
It seems to depend on the use case and configuration of the device.
Despite Nokia's 'multimedia computer' tag. The engineering challenges in building reliable mobile terminals are not the same as a PC.
>> Depression is unfit, you may suddenly decide to kill the boss
Jeeze, last time I checked it was called heathy grieving and seemed to be a widely accepted side effect of death of a close one. It's really not useful to label grief and it's associated feelings as a sickness.
You just don't know what the relationship of the person with his firm or how competent his manager was at dealing with someone who couldn't work. (especially in a small company where absent individials impact the business in a big way).
Who knows. The guy might have been usless at his job. But he lost his brother an his job at the same time which sucks.
Microsoft know about compatibilty, it was their bread and butter for a long time.
Old Joel posting illuminates: http://www.joelonsoftware.com/articles/APIWar.html
On Vista, MS removed the old help system. But users can download from the windows site (except I doubt that it's tested any more).
Basically, users can get it to work - but most users will not understand or be bothered to download the "legacy help system". And by presenting it in this manner, ISVs are forced to spend money porting their help system to the vista one (meaning that they have to maintain two - one for XP and one for vista).
Java like vista and any other have an economy built on top, any removal of a public API is going to ripple problems through the ecosystem causing end users to pay more in the end. Those banks that might have built everything on top of AWT will pass the rewrite charges onto their customers eventually.
A platform is for life not just for mishmash.
We may as well stop wasting words until something concrete emerges.
The android web site is very poor. The characters in the 'making of' interviews are not only uninspring, but offputting.
The info talks about android being able to blend web and phone data so that when you are in the vicinity of a friend a "poke me" type request can pop up on each phone so that you can meet up and have an overpriced cup of coffee. Bloody hell , that's exactly what dot commers were pedling back in 1999 - LBG (location based guilt).
The web site also mentions a VM which optimises for low memory, slower performance devices. So if there is a VM, the "android apis" are not native.
It sounds very much like the JavaOS type of propostion. Nothing new, but then google have a good track record of doing things well rather than doing things first.
To paraphase erm, Mark Watson i think:
"PC on a phone? I can take a shit in dishwash. Doesn't make it right"
Nokia actually have an example of using java based location serverices based on JSR-179. It seems to run ok on the N95.
http://tinyurl.com/32xf9k
A couple of things.
Java has a huge fragmentation problem with handset manufacturers and operators each wanting to add their own APIs, libraries and security. If JavaFx is introduced then it will have to coexist happily with J2ME for a good few years (including supplying compatible mobile LCDUI classes). Operators want a platform to deploy single apps and updates accross all phones - it cost them a lot of money to support multiple platforms.
J2ME can do a hell of a lot more than "widget" based apps. There are JSRs for bluetooth, SIP, OpenGL. While a web app can't even draw a graph (how do you draw a line or bezier curve in XHTML?) without getting the server to generate it.
I think James Gosling is generally regarded as the creator/inventor of Java. Last time i checked software isn't made from the DNA leaked from the programmer's finger tips.
As far as I see it. Java is pretty simple as the core language definition which makes it good for re-usable algorithmic code, but further confusing product, segmentation and Java brand seems to be doing more bad than good.
Are google looknig at native for performance, or is it to avoid dabbling in APIs so heavily influenced by the ops?
That's not entirely true Dominic. You can allow "self signed" apps to be installed by changing a menu setting which grants the application. This allows you to install applications with very basic capabilities (LocalServices,• UserEnvironment,• NetworkServices, ReadUserData,WriteUserData).
On install, the user is told about the basic capabilities that the app requires and can abort or continue to install. (Bruce Shneier has some good material on his blog regarding the problems with asking the user to make security decisions).
A posting on forum nokia indicates that around 60% of the APIs on S60 are available to self signed applications, which does actually give then developer a fair set of APIs to play with. You can draw to the screen, pop up dialogs, persist data to the app's home directory and quite a bit more.
Sensitive services (meaning - access to user's personal data, location or services that can spend money) are only available through the Symbian signed process.
The option that you are seeing on the E61 can be configured by the handset manufacturer/operator. In fact, if they wish, they can hardcode devices to only allow Symbian signed apps if they feel that the self signed criterion is too liberal.
I think it's sensible that Apple at least wait until they get the security model raionalised and tested by their close partners before opening up the phone. It's very hard to close off an API after it has been open and used and relied on by 3rd parties.
When building a open device, you want some level of sandboxing not just for security marshalling but also to allow the core code to evolve and be re-factored without breaking 3rd party apps in each update. If I was Steve - I wouldn't rush anything either.
I think that equating unitentionally bloated code with maliciously peppering your code with sleeps() is a bit of a puzzeling comparison to draw.
There is not much point in a high level language if you have to keep looking at the ASM listings because you don't trust it.
Firstly you should always look at the release output - the simple fix to bloated debug code is to release- release code.
One reason for debug output being bloaty is that a debugger needs to be able to work back to the line that originated the asm section, this not only means many optimisations are not on the cards, but also things like inline functions may have a different effect.
So the fact that the article spends most of it's time picking apart the of debug is a bit bogus.
Mutiple calls to NSUserDefaults is just bad software engineering. Readibilty is improved by refactoring the code to use one instance.
Thanks for pointing out the potential cost of the dispatch though, it's good to know.
In companies that I have worked in. Patterns of code which produced code bloat were documented as things to avoid as part of the coding standard, and applied during peer review.